I am confused by the term "Common Controls", are Windows controls divided between common controls and non-common controls?
I tried to search for a list of common controls but I couldn't find anything, if not all controls in windows are common controls, can I get a list of the common controls?
Simply put, the "common controls" are those implemented by comctl32.dll, the first of which made an appearance in Windows 95. They are:
Animation
ComboboxEx
Date/time picker
Header
Hotkey
Hyperlink (Syslink)
IP address
Listview
Pager
Progress bar
Rebar
Status bar
Tab
Toolbar
Tooltip
Trackbar
Treeview
Up/down
They are distinct from the controls implemented by user32.dll which are the "original" Windows controls (dating back to 16-bit Windows): BUTTON, EDIT, LISTBOX, COMBOBOX, STATIC and SCROLLBAR.
I would use Windows Controls and Common Controls quite exchangeable, but it seems that if you want to be strict there are (basic) Windows Controls and (enhanced) Common Controls.
Windows Controls says that Windows Controls are child windows and that a complete list is available in the Control Library. This is quite a long list and includes for example buttons, edit fields, tree views and date and time pickers.
The MSDN page About Windows Classes gives you a list of basic windows classes. The controls listed there are only the basic ones like buttons and edit fields.
The MSDN page About Common Controls says that common controls are implemented by the common control library Comctl32.dll. Creating Common Controls says that you should load Comctl32.dll by calling InitCommonControlsEx providing the controls you need. There are bits for different classes, for example for tree views and data and time pickers.
Summing it all up: the list in the Control Library seems to be the complete list of all controls. These are either (basic, simple) Windows Controls (for a list see About Windows Classes) or (more complex and more featured) Common Controls (for a list see INITCOMMONCONTROLSEX).
Related
If you open settings of wifi and choose any network you will see Password textbox and BUTTONS (not icons) in ApplicationBar. How it is made? Is it some kind of ApplicationBar template? Or it is some Border control, but how to show a Border above the SIP(keyboard)?
Any ideas how to make the same thing?
What are you describing was not created using Silverlight (all the "hero" applications are done in C++) and are therefore not limited by the current SL feature set.
In relation to your actual question, it is not possible to template the ApplicationBar nor is it even possible to determine when the SIP is displayed (or what its height is).
In short, I'd stick to icons if you want your application to work well across devices.
I have built a wizard style user control that lets you add stackpanel based pages and flick between them.
I would like to add an application bar as part of the user control with next and previous buttons that enable/disable based on page displayed etc.
Application bar appears to be an attached property of PhoneApplicationPage. I have tried referencing Microsoft.Phone.Shell but get invalid type.
Any ideas how I can add it to my user control?
Application bar is such a pain in the a**. This control is not a Silverlight one but a native one. Maybe you can be more lucky with this solution:
http://blog.humann.info/post/2010/08/27/How-to-have-binding-on-the-ApplicationBar.aspx
The ApplicationBar is a service that is provided by the operating system, i.e. not part of the Framework, and can only be used at the page-level, not in your UserControl. In addition, the ApplicationBar does not support regular bindings as you've seen. As mentioned above there are a number of solutions that provide workarounds for this problem.
Alternatively, you could use the ApplicationBarButtonCommand and ApplicationBarButtonNavigation behaviors from the Silverlight Windows Phone Toolkit. It's a simple enough task to create your ApplicationBarMenuCommand if you need one.
In other words, if I want to write a winforms db application with an appearince like VS that has docked panels and also the ability to show/hide forms within some of those panels, how would I structure the interface? How would I have the ability to open several disparate forms at different times (with big data grids on them) while avoiding floating forms and also using memory efficiently? I want to avoid floating windows.
Check out this article to build a VS like interface:
Visual Studio IDE like Dock Container
I haven't tried the component myself but it looks interesting.
Visual Studio is definetly MDI
In the technical sense, Visual Studio is an MDI application whose document windows are anchored by tab navigation.
MDI refers to "multiple document interface," and refers to the fact that there are multiple documents open and visible inside a larger parent window.
In the modern application development realm, typically MDI has been frowned upon -- but that was the "old school" MDI, with the free-floating windows. Those are widely considered to be a usability nightmare.
On the other hand, MDI implemented as tabs inside a parent window is so successful from a UI consideration that even environment which didn't traditionally have MDI (EG, Mac OS) are implementing them.
In order to implement something like this, you can "roll your own," or you can use any of a variety of custom control/API packages which will allow you to easily develop tabbed-interface MDI apps. One of the last things I did with Infragistics NetAdvantage (before moving away from it) was a Visual Studio-inspired app, with docking sidebars, search results as a pane at the bottom, and all the primary data forms as tabbed MDI documents. (Indeed, WinForms is one of the few places Infragistics really shines.)
In terms of memory management, that will be on you. :)
I think technically Visual Studio would be classed as an MDI.
The main form holds disparate controls. Each of these controls can then be docked as required etc. Visual Studio for example has a single control (with multiple tabs) to display the documents you edit. A single control with multiple tabs that holds (eg) Solution Explorer, Properties etc etc.
As a starting point to creating your own IDE style interface I would create a form with 5 panels, one docked to top, one to left, one to right, one bottom and one 'fill'
Thats your starting point. Add splitter bars to allow the panels to be resized. Each panel can then hold a Tab control, and each tab holds a 'MdiBaseControl'
An MdiBaseControl can be whatever you want. So in VS terms you have things like SolutionExplorer, Properties, Breakpoints, FindResults etc etc.
Each MdiBaseControl can be dragged from its current tab and dropped into any of the docked panels (which then adds it to the Tab control as a new tab)
I just noticed that Developer Express have some controls for building IDE-style interfaces.
In both interfaces, multiple forms can be seen at the same time but in MDI, things float freely. In this sense, Visual Studio is a SDI.
In Vista and Windows 7 almost any time the system uses a standard Listview (ie: Explorer Windows) it's accompanied by a little split button that shows a slider when the split is clicked that allows you to switch between the different views available for that listview (Tile, Details, List, etc.) as well as sliding smoothly between icon sizes (from 32x32 is to 256x256) using the top half of the slider.
This is a cool little bit of functionality, so I was wondering: Is that control available to developers, and if so what is it called and where is it documented? (Win32/C++ preferred)
Turns out in Windows 7, the explorer window is no longer a standard listview (though it does an extremely good job of looking like one). Open Spy++, point it at an explorer window list pane, and you'll see a classname of "DirectUIHWND" instead of the old "SysListView32".
The actual slider itself is indeed a real ComCtl32 slider; so you could perhaps roll your own; but as far as I know there's no way to reuse the existing explorer pane's functionality.
I have a custom control: it's managed code, which subclasses System.Windows.Forms.Control.
I want to add things like edit boxes, selection lists, combo boxes, radio buttons and so on to places on this control. An easy way to do this is to simply add instances of these classes to the Controls collection, so that they become child controls.
Adding them as child controls might create some subtle problems, for example:
IE 6 select controls(Combo Box) over menu
I have scrollbars on my control which appear to scroll the contents of the control (the contents are bigger than the control itself); when a child control is near the edge of the screen then I'd like to half-display (i.e. clip) that child (i.e. to have half of it located off the edge of the physical screen), but a true child control cannot be located outside the border of its parent.
Are there other potential problems?
When I use IE7 to display http://www.tizag.com/htmlT/htmlselect.php (for example), which contains combo boxes etc., and when I then use Spy++ to spy on IE7 when I'm doing that, I see only a single Window/control instance with no children (whose class name is "Internet Explorer_Server").
I'm guessing this means that in IE7, the functionality to render a combo box is built in to the IE7 control itself, and that IE7 does not use standard controls as child controls.
Questions:
Is it better to reuse standard controls as children of a custom control, or, to reimplement the functionality of standard controls within a custom control itself?
Do you have any caveats (warnings) to share, related to either scenario?
If I wanted to reimplement the functionality of standard controls within a custom control, do you know of any existing code (which implements this functionality) that I could re-use?
If such code already exists, I don't know how to search for it (my searches find, for example, owner-draw combo boxes, and extensions to standard combo boxes): perhaps few people reimplement the standard controls from scratch?
Edit
I found a semi-related question: How to render a control to look like ComboBox with Visual Styles enabled?
Yes, Internet Explorer draws the controls using the Windows theming APIs. You can do this too using the types defined in the System.Windows.Forms.VisualStyles namespace.
The IE team did this to avoid performance problems of having so many controls, each receiving window messages, on screen at once. For example, looking at this StackOverflow.com page, I see 30-40 link label controls, 10 buttons or so, 20+ labels, etc.
It should be noted the Zune software, which is .NET managed code, also uses custom controls; if you try to use Spy++ on any of the controls, you'll see they aren't real Win32 controls. You may use Reflector on the Zune software to see exactly what they're doing. If I recall right, they're using a custom managed UI framework that's included in the Zune software.
As far as rewriting these controls from scratch, I think there's a ton of work to be done. It sounds easier than it really would be.