Controls for Windows apps

In Windows app development, a control is a UI element that displays content or enables interaction. Controls are the building blocks of the user interface. A pattern is a recipe for combining several controls to make something new.

We provide 45+ controls for you to use, ranging from simple buttons to powerful data controls like the grid view. These controls are a part of the Fluent Design System and can help you create a bold, scalable UI that looks great on all devices and screen sizes.

The articles in this section provide design guidance and coding instructions for adding controls & patterns to your Windows app.

Intro

General instructions and code examples for adding and styling controls in XAML and C#.

Add controls and handle events
There are 3 key steps to adding controls to your app: Add a control to your app UI, set properties on the control, and add code to the control’s event handlers so that it does something.

Styling controls
You can customize the appearance of your apps in many ways by using the XAML framework. Styles let you set control properties and reuse those settings for a consistent appearance across multiple controls.

Get the Windows UI Library

Some controls are only available in the Windows UI Library (WinUI), a NuGet package that contains new controls and UI features. To get it, see the Windows UI Library overview and installation instructions.
Starting with WinUI 2.2, the default style for many controls has been updated to use rounded corners. For more info, see Corner radius.

Alphabetical index

Detailed information about specific controls and patterns.

• Animated visual player (see Lottie)
• Auto-suggest box
• Button
• Calendar date picker
• Calendar view
• Checkbox
• Color picker
• Combo box
• Command bar
• Command bar flyout
• Contact card
• Content dialog
• Content link
• Context menu
• Date picker
• Dialogs and flyouts
• Drop down button
• Flip view
• Flyout
• Forms (pattern)
• Grid view
• Hyperlink
• Hyperlink button
• Images and image brushes
• Inking controls
• List/details (pattern)
• List view
• Map control
• Media playback
• Menu bar
• Menu flyout
• Navigation view

• Number box
• Parallax view
• Password box
• Person picture
• Pivot
• Progress bar
• Progress ring
• Radio button
• Rating control
• Repeat button
• Rich edit box
• Rich text block
• Scroll viewer
• Search (pattern)
• Semantic zoom
• Shapes
• Slider
• Split button
• Split view
• Swipe control
• Tab view
• Teaching tip
• Text block
• Text box
• Time picker
• Toggle switch
• Toggle button
• Toggle split button
• Tooltips
• Tree view
• Two-pane view
• Web view

XAML Controls Gallery

Get the XAML Controls Gallery app from the Microsoft Store to see these controls and the Fluent Design System in action. The app is an interactive companion to this website. When you have it installed, you can use links on individual control pages to launch the app and see the control in action.

Additional controls

Additional controls for Windows development are available from companies such as Telerik, SyncFusion, DevExpress, Infragistics, ComponentOne, and ActiPro. These controls provide additional support for enterprise and .NET developers by augmenting the standard system controls with custom controls and services.

What is the difference between System.Windows.Controls.Control and System.Windows.Forms.Control?

I’m confused, can anyone help me out?

Edit

My problem is that I have created an ActiveX control in Delphi and I just can’t get it to play nicely in WPF land. I have looked at the relevant MSDN pages, and it looks like it SHOULD work, so I may have gone wrong in the way that I have created the ActiveX control in the first place.

6 Answers 6

Have a look at the official documentation for both classes

Here is the Class signature for System.Windows.Controls.control class

Here is the Class signature for System.Windows.Forms.Control class

They are controls that live in completely different worlds.

System.Windows.Controls.Control is a WPF control.

System.Windows.Forms.Control is a WinForms control.

The choice is pretty simple. If you are developing a WinForms app — use WinForms controls. Similarly, if you are writing a WPF app — use WPF controls.

As for choosing between WPF and WinForms — this question might help.

System.Windows.Controls.Control is for WPF application

System.Windows.Forms.Control i s for Winforms application.

System.Windows.Forms.Control
Defines the base class for controls, which are components with visual representation.

System.Windows.Controls.Control
Represents the base class for user interface (UI) elements that use a ControlTemplate to define their appearance.

What is Windows Presentation Foundation and Windows Forms?

You should be able to determine that from the namespace that one is the base Control class for WPF (all WPF uses the .Windows naming) and the other is for Windows Forms.

Can you clarify what exactly you find confusing? I will update my answer.

Can’t Move Controls With Mouse on Windows Form Designer

I recently installed Visual Studio 2013 Professional, and found that in the Windows Forms Application project type I’m unable to move any controls on a form in design mode. I tested a few alternatives out and found the following:

• Controls can be moved with the keyboard
• Controls can be resized by dragging the keypoints on the outline of the control
• Controls can be aligned using the commands in the Tools menu
• Controls can be moved by setting the Location field manually in the designer property grid
• Controls can be docked
• Controls cannot be moved with the mouse

Furthermore, as you can see in the image below, the «cross» icon that indicates that the controls are movable is not visible on any controls.

I’ve tried the following, but have not yet been able to correct the issue:

• Created a new project & solution (same issue)
• Created a new form (same issue)
• Verified that the Locked property of both the form and controls is set to False
• Verified that the form inherits from Form (as expected, as this is a standard installation and the first time I’ve used it)
• Googled for help (nothing that worked)

Any suggestions would be appreciated.

10 Answers 10

It took some time but I finally found a workaround, if not an answer. As it happens, periodically my computer will stop allowing me to drag-and-drop anything. The solution to this is to press the Esc (escape) key, which instantly restores functionality.

I had this happening using multiple monitors. Move VS to the main monitor (1) and all will work fine. Greetz

I know this is an older thread, but this problem still persists. I am putting this here because I think some of these may work for others. The top option works for me, but is by no means a permanent solution. It helps to get your project completed though. Design your forms on your main screen then move VS to your secondary monitor to code kinda thing. I work off a laptop, so I don’t like working on a small screen.

Some steps are rudimentary, but I was trying to be thorough. Sometimes it’s the simple solution.

• Moving VS to main monitor(1) — this worked for me, but still doesn’t allow me to use my 2 monitors
• Run installer, select Repair
• Run and cancel your project
• Press the Esc button and see if things return to normal
• Right click form «Lock Controls». This should not have the blue outline, or right click on form/control>Lock Controls and make sure nothing is locked.
• Rebuild project, close and open the form again.
• Snap to grid setting — Tools>Options>Windows Form Designer>General
• Restart VS with 100% scaling — drawing may be an issue. I am not convinced it is not here since it works on the main screen but not the 2nd or 3rd
• Dock property set to none for form/controls
• Moving items very slowly with mouse — another indication drawing may be an issue.
• Controls may not be docked in the container in which they reside. Restart VS. Try double clicking on the control, then move. I think this is indicative of creating the control outside a container(say, on a form), dragging it into another container(say, a tabControl) and then it not moving within that tabControl. Additionally, try creating new controls within their intended container and then trying to move them.
• Close VS, delete C:\Users\user.name\AppData\Local\Microsoft\VisualStudio\15.0_xxxxxxxxx folder
• Mouse driver — some software may cause issues here.
• Absolute positioning — Tools>Options>Web Form Designer>CSS Styling>Change position.
• Right click any item under toolbox and select «reset toolbox»

Close VS. Delete some config files with current dates (devenv.exe.config, toolbox.tbd, toolbox_reset.tbd, toolboxindex.tbd, toolboxindex_reset.tbd) and reboot the PC. These are found in a directory like C:\Users\tdevy97\AppData\Local\Microsoft\VisualStudio\15.0_18c2eb4a where the last folder(15.0_18c2eb4a) is some random name. Reboot. Restart VS.

Corrupt toolbox? Close Visual Studio, Open the “c:\Users\AppData\Local\Microsoft\VisualStudio\14.0” folder and remove all the .TBD files, Start regedit, Find the “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\ToolboxControlsInstaller_AssemblyFoldersExCache” and “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\ToolboxControlsInstallerCache” keys, Remove everything from these keys leaving them empty, before you removing it, (back up your registry first), Reboot, Run Visual Studio again and wait until it recreates all items in the toolbox.

Open command prompt as admin, navigate to your «IDE» directory (C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE) and run the following commands.

Best way to access a control on another form in Windows Forms?

First off, this is a question about a desktop application using Windows Forms, not an ASP.NET question.

I need to interact with controls on other forms. I am trying to access the controls by using, for example, the following.

It doesn’t work the way I would expect. I end up with an exception thrown from Main . However, if I make the controls public instead of private , I can then access them directly, as so.

But is that the best way to do it? Is making the controls public on the other form considered «best practice»? Is there a «better» way to access controls on another form?

Further Explanation:

This is actually a sort of follow-up to another question I asked, Best method for creating a “tree-view preferences dialog” type of interface in C#?. The answer I got was great and solved many, many organizational problems I was having in terms of keeping the UI straight and easy to work with both in run-time and design-time. However, it did bring up this one niggling issue of easily controlling other aspects of the interface.

Basically, I have a root form that instantiates a lot of other forms that sit in a panel on the root form. So, for instance, a radio button on one of those sub-forms might need to alter the state of a status strip icon on the main, root form. In that case, I need the sub-form to talk to the control in the status strip of the parent (root) form. (I hope that makes sense, not in a «who’s on first» kind of way.)

17 Answers 17

Instead of making the control public, you can create a property that controls its visibility:

This creates a proper accessor to that control that won’t expose the control’s whole set of properties.

I personally would recommend NOT doing it. If it’s responding to some sort of action and it needs to change its appearance, I would prefer raising an event and letting it sort itself out.

This kind of coupling between forms always makes me nervous. I always try to keep the UI as light and independent as possible..

I hope this helps. Perhaps you could expand on the scenario if not?

The first is not working of course. The controls on a form are private, visible only for that form by design.

To make it all public is also not the best way.

If I would like to expose something to the outer world (which also can mean an another form), I make a public property for it.

You can use this public property to hide or show the control or to ask the control current visibility property:

You can also expose full controls, but I think it is too much, you should make visible only the properties you really want to use from outside the current form.

After reading the additional details, I agree with robcthegeek: raise an event. Create a custom EventArgs and pass the neccessary parameters through it.

Suppose you have two forms, and you want to hide the property of one form via another:

and when you want to get focus back of form1 via form2 button then:

I would handle this in the parent form. You can notify the other form that it needs to modify itself through an event.

1. Use an event handler to notify other the form to handle it.
2. Create a public property on the child form and access it from parent form (with a valid cast).
3. Create another constructor on the child form for setting form’s initialization parameters
4. Create custom events and/or use (static) classes.

The best practice would be #4 if you are using non-modal forms.

1. Create a public method with needed parameter on child form and call it from parent form (with valid cast)
2. Create a public property on child form and access it from parent form (with valid cast)
3. Create another constructor on child form for setting form’s initialization parameters
4. Create custom events and/or use (static) classes

Best practice would be #4 if you are using non-modal forms.

With the property (highlighted) I can get the instance of the MainForm class. But this is a good practice? What do you recommend?

For this I use the property MainFormInstance that runs on the OnLoad method.

I agree with using events for this. Since I suspect that you’re building an MDI-application (since you create many child forms) and creates windows dynamically and might not know when to unsubscribe from events, I would recommend that you take a look at Weak Event Patterns. Alas, this is only available for framework 3.0 and 3.5 but something similar can be implemented fairly easy with weak references.

However, if you want to find a control in a form based on the form’s reference, it’s not enough to simply look at the form’s control collection. Since every control have it’s own control collection, you will have to recurse through them all to find a specific control. You can do this with these two methods (which can be improved).

@Lars, good call on the passing around of Form references, seen it as well myself. Nasty. Never seen them passed them down to the BLL layer though! That doesn’t even make sense! That could have seriously impacted performance right? If somewhere in the BLL the reference was kept, the form would stay in memory right?

You have my sympathy! 😉

@Ed, RE your comment about making the Forms UserControls. Dylan has already pointed out that the root form instantiates many child forms, giving the impression of an MDI application (where I am assuming users may want to close various Forms). If I am correct in this assumption, I would think they would be best kept as forms. Certainly open to correction though 🙂

Do your child forms really need to be Forms? Could they be user controls instead? This way, they could easily raise events for the main form to handle and you could better encapsulate their logic into a single class (at least, logically, they are after all classes already).

@Lars: You are right here. This was something I did in my very beginning days and have not had to do it since, that is why I first suggested raising an event, but my other method would really break any semblance of encapsulation.

@Rob: Yup, sounds about right :). 0/2 on this one.

You should only ever access one view’s contents from another if you’re creating more complex controls/modules/components. Otherwise, you should do this through the standard Model-View-Controller architecture: You should connect the enabled state of the controls you care about to some model-level predicate that supplies the right information.

For example, if I wanted to enable a Save button only when all required information was entered, I’d have a predicate method that tells when the model objects representing that form are in a state that can be saved. Then in the context where I’m choosing whether to enable the button, I’d just use the result of that method.

This results in a much cleaner separation of business logic from presentation logic, allowing both of them to evolve more independently — letting you create one front-end with multiple back-ends, or multiple front-ends with a single back-end with ease.

It will also be much, much easier to write unit and acceptance tests for, because you can follow a «Trust But Verify» pattern in doing so:

You can write one set of tests that set up your model objects in various ways and check that the «is savable» predicate returns an appropriate result.

You can write a separate set of that check whether your Save button is connected in an appropriate fashion to the «is savable» predicate (whatever that is for your framework, in Cocoa on Mac OS X this would often be through a binding).

As long as both sets of tests are passing, you can be confident that your user interface will work the way you want it to.

This looks like a prime candidate for separating the presentation from the data model. In this case, your preferences should be stored in a separate class that fires event updates whenever a particular property changes (look into INotifyPropertyChanged if your properties are a discrete set, or into a single event if they are more free-form text-based keys).

In your tree view, you’ll make the changes to your preferences model, it will then fire an event. In your other forms, you’ll subscribe to the changes that you’re interested in. In the event handler you use to subscribe to the property changes, you use this.InvokeRequired to see if you are on the right thread to make the UI call, if not, then use this.BeginInvoke to call the desired method to update the form.

Change modifier from public to internal. .Net deliberately uses private modifier instead of the public, due to preventing any illegal access to your methods/properties/controls out of your project. In fact, public modifier can accessible wherever, so They are really dangerous. Any body out of your project can access to your methods/properties. But In internal modifier no body (other of your current project) can access to your methods/properties.

Suppose you are creating a project, which has some secret fields. So If these fields being accessible out of your project, it can be dangerous, and against to your initial ideas. As one good recommendation, I can say always use internal modifier instead of public modifier.

But some strange!

I must tell also in VB.Net while our methods/properties are still private, it can be accessible from other forms/class by calling form as a variable with no any problem else.

I don’t know why in this programming language behavior is different from C#. As we know both are using same Platform and they claim they are almost same Back end Platform, but as you see, they still behave differently.

But I’ve solved this problem with two approaches. Either; by using Interface (Which is not a recommend, as you know, Interfaces usually need public modifier, and using a public modifier is not recommend (As I told you above)),

Declare your whole Form in somewhere static class and static variable and there is still internal modifier. Then when you suppose to use that form for showing to users, so pass new Form() construction to that static class/variable. Now It can be Accessible every where as you wish. But you still need some thing more. You declare your element internal modifier too in Designer File of Form. While your Form is open, it can be accessible everywhere. It can work for you very well.

Consider This Example.

Suppose you want to access to a Form’s TextBox.

So the first job is declaration of a static variable in a static class (The reason of static is ease of access without any using new keywork at future).

Second go to designer class of that Form which supposes to be accessed by other Forms. Change its TextBox modifier declaration from private to internal. Don’t worry; .Net never change it again to private modifier after your changing.

Third when you want to call that form to open, so pass the new Form Construction to that static variable—>>static class.

Fourth; from any other Forms (wherever in your project) you can access to that form/control while From is open.

Look at code below (We have three object. 1- a static class (in our example we name it A )

2 — Any Form else which wants to open the final Form (has TextBox, in our example FormB ).

3 — The real Form which we need to be opened, and we suppose to access to its internal TextBox1 (in our example FormC ).

Look at codes below:

You can access to that static Variable (here FormC ) and its internal control (here Textbox1 ) wherever and whenever as you wish, while FormC is open.

Any Comment/idea let me know. I glad to hear from you or any body else about this topic more. Honestly I have had some problems regard to this mentioned problem in past. The best way was the second solution that I hope it can work for you. Let me know any new idea/suggestion.