You can tell that a standard push button in Windows XP looks different than a standard push button in WIndows 2000, and such one in Windows Vista. On top of it, since XP Windows supports visual themes. The interesting thing is that sometimes one and the same application keeps its Windows 2000 look, but sometimes standard push buttons follow the way of XP, or the Vista, depending on where you run it.
In this article I explain why.
Windows controls are visual elements, which allow users to interact with the application. Windows controls are actually child windows, which live in a parent window - a dialog box or any window in general.
There are two types of Windows controls - common controls, and custom controls. Common controls are provided by Windows itself, and it is them I will speak about in this article. These include buttons, static text and basic shapes, edit boxes, combo boxes, list boxes, scroll bars, rich edit boxes, tabs, toolbars, etc. The full list can be found here. Custom controls are made by programmers for their applications. Since a control is a child window, developers can create basically everything they can think of - like animated, flashing buttons with twisted irregular shape.
Common controls are very important. First, common controls save you time. They are provided by the operating system, they are well-tested and ready to use controls, which can be very easily embedded into any application.
Second, common controls express the view of the designers of the operating system and mainly its graphical user interface (GUI) about how applications should look and behave, in order to match the usability requirements, and the general look and feel of the GUI in question. Microsoft is among the companies who care quite a lot for user friendliness of the GUI. There is a splendid document on the subject - Windows Vista User Experience Guidelines, which summarizes all their research on the topic. I strongly recommend this reading to every developer and system architect.
In other words - use common controls as much as possible! Fancy interface does not always mean good. Actually, more often than not the fancier the interface, the more confusing it is for the end user. When a user sees a button, one should be able to realize immediately that it is a button. If it takes a user minutes to realize what the damn fancy picture is all about, then you’ve done it all wrong.
Enough beating around the bush, lets go back to the story of different looks of controls.
Here is a good short article of how Windows XP controls emmerged, what problems they were facing, and how they were solved. I don’t think I can contribute much to Raymond Chen on this subject here.
Suffice to summarize - starting from XP Windows supports two versions of common controls, and it is up to the application to tell the OS which set it would use. Older applications don’t know about it and automatically receive the old set. Newer ones can ask for theme-enabled, or UX controls.
In order to enable visual themes, your application should provide a manifest. The manifest is an XML content which tells Windows which version of the common controls it will use. Hardcore details about manifests and visual themes can be found here.
Common Controls in Windows Forms (.NET Framework)
Support for visual themes was added in .NET Framework 2.0. Visual themes are enabled by default in Windows Forms applications in .NET Framework 2.0 and newer. This means, that common windows controls, used in WIndows Forms applications - buttons (including radio buttons and check boxes), text boxes, list boxes, combo boxes, scroll bars, etc., are actually provided by the OS. Note that controls like menustrips and grids are not common controls.
Windows Forms applications can control whether to use visual themes by using property VisualStyleState of class Application. You can change it at run time, while you application is running. Don’t forget to invalidate your forms (Form.Invalidate(true)) to make changes take effect.
Controls in WIndows Presentation Foundation
Controls in WPF applications have nothing to do with Windows common controls. They are drawn and managed exclusively by NET Framework runtime. In terms of Win32, WPF forms are one single window, and all controls are actually drawn inside it. In special cases like menus and drop down boxes, where elements of conrols can appear outside the boundaries of the WPF form, additional Win32 window can be created.
WPF applications automatically detect the theme of the OS, and apply it on its controls.