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.
Related
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).
I want to get a list of all UI elements of a window, In a way I can recreate them on another PC? Currently I am focused on windows but a multi-platform answer will be greatly appreciated. Thanks! (What I mean below)
There are a couple of ways to go.
Option 1: If the window is a traditional one where the UI elements are child windows (rather than windowless controls), then you can use GetWindow or EnumChildWindows to iterate through the UI elements in a given window. You then would have to examine attributes of those windows, like the window procedure, window styles, and window text, to build a list like you're suggesting. You could probably make this work for all the standard controls. The problem is making it general enough to handle everything. Lots of applications have custom control types that your code wouldn't be prepared to recognize, or it might lay them out in ways that aren't obvious. You also won't be able to deal with windows that use windowless controls.
Options 2: You can use UI Automation to walk the tree of UI controls. This is how accessibility technologies like screen readers interact with applications.
I am new to GUI programming in Windows.
The Windows Resource Monitor (perfmon.exe /res) has four bars (CPU/Disk/Network/Memory) that have gradient backgrounds, as well as charts on the right for displaying recent CPU/Disk/Network/Memory usage.
I am wondering what kind of controls were used in this application. Are they readily available in C++ or in C#?
They are custom controls that are not available for external use, sorry.
You can use the Spy++ window finder tool (Spy++ is included with DevStudio) to find the window class names (and window boundaries).
http://msdn.microsoft.com/en-us/library/aa266028(v=vs.60).aspx
It shows that the overall window is a DirectUIHWND, the graphs are windows but the bars labelled CPU/Disk/Network, etc are not windows at all, the appear to be drawn directly in the resource monitors client area.
The implementation is not public for these controls, but I'm pretty sure they are incorporated using Windowless Controls.
Those bars remind me of Outlook bars. One old implementation is described in Code Project, and that one also has no windows on its own. Everything is painted inside.
Edit: That Code Project article was C# port. For C++ original go to Code Guru.
Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).
However, how do all of these programs like Word or google’s Chrome browser alter the standard windows’ window? I thought it was somehow protected?
Chrome seems to have tabs actually on the window’s frame?
I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).
I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.
I hope this question is clear!
Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:
http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx
Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.
Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.
Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.
There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)
We need to automate GUI testing of an application developed in Win32 API. Developer's have created this application by custom painted controls. They have controls which look like Grid, Buttons etc., but they are not basic Windows controls.
What is custom painted controls? and how we can test these controls?
Test it just like any other UI: Not at all. Move all code out of the callbacks into the application layer where your unit tests can execute them just like any other method.
Rationale: There is little point in testing whether "button.activate()" works; you want to know whether the your code behind the button callback works.
If you need to know whether the correct dialogs, etc., are opened, see my blog: Testing the Impossible: User Dialogs
Have the developers added support for accessibility using IAccessible? If they have, you can use active accessibility to navigate through the controls and test them that way.
If they haven't, open a bug that says that their controls can't be use by disabled people (who need a screen reader or other accessibility aid).
Once they fix that bug, you can use whatever mechanism they added to their controls to allow them to be used by screen readers and other accessibility aids to test their UI.