I have a VB6 program which uses comctrl32.ocx to display a progress bar. I've also had programs using mscomctl.ocx. However, it is displaying it using the ugly, old-style blue boxes progress bar instead of using the new-style progressbar (which presumably varies depending on the OS). Other programs which reference that same ocx file display the new-style progressbar (unless I run them VB6, in which case they still use the ugly one). All of the properties of the control are the same. Any suggestions on what I'm doing wrong?
Most likely, your application doesn't have a manifest and therefore uses the old pre-Windows XP style common controls. vbAccelerator has a great article on how to add one
Related
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)
Previously I used to piddle around with VB6 to develop a couple of personal projects. Following my upgrade to Windows 7, I've decided to piddle about with vb.net Express Edition 2010.
If I wanted my VB6 application to blend in with the visual style of Windows, I would use the code and techniques described here. In short, I would use a Manifest file and a couple of calls within the application and most of the elements would look similar to the XP theme applied. If it was run on 2000, 95 or 98 then it would look like a standard Windows app. All was good.
Now I've moved onto vb.net, I've written a simple "Hello, world" application but I have absolutely no idea on how to make it look like the Windows 7 theme (eg. the font matches the system font and the widgets are styled correctly).
Just changing the font is a hack and will look out of place on machines that are set-up differently or run a different version of Windows where the default font is different.
How do I ensure my application matches the applied Windows theme irrespective of the version of Windows?
A lot of this is automatic if you create a Windows Forms app. They will (mostly) use the standard native Windows controls which draw themselves with the theme colors. But there are exceptions:
the Form item template uses a default Font named Microsoft Sans Serif. You'll have to change it to Segoe UI to match the Vista/Win7 default. This is only necessary for the Form class, all controls you put on it will automatically inherit that font. On an XP machine, the Windows font mapper will notice that the font is missing and automatically fall back to MSS.
the MenuStrip class uses custom rendering to draw the menu items. It tries to match the Windows style when you change the RenderMode property to System but the way it draws doesn't match the Win7 style. Right-click the toolbox, Choose Items and select MainMenu. That's a legacy version that does use Windows to draw menus so it produces the proper theme appearance.
A very similar problem for ToolStrip. It's legacy version is ToolBar. This is a hard one to swallow, it doesn't use a rebar which make the tool bar look flat and ugly.
There are similar problems in WPF but with the added problem that WPF doesn't use any of the standard Windows controls. And gets it wrong in subtle places.
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.