Reader Martin Payne wrote:
I would be grateful if you could try to solve a problem I have using your resizable dialogs article from October 2000. I found this article immensely useful. However, I have one problem when using it:
If the dialog contains a group box, although it is initially displayed correctly, when the dialog box is resized, the background of the group box is not displayed correctly. Is this because it is transparent, or somehow not refreshed properly? Have you any idea about how to solve this problem?
I would be very grateful if you could find time to reply.
Thanks!
Group boxes have a certain strangeness about them, and the transparent hole they have in the middle is at the root of the problem. To check out Martins question, I added group boxes to my original demo dialog, and presto! it looked like Figure 1 a dialog box that fails to paint its background underneath the group box. Both Martin and I would prefer the dialog box to look more like Figure 2.
The serious part of the trouble turns out to be the WS_CLIPCHILDREN style bit. I originally set this style bit on the dialog because it visibly reduces flashing during resizing. But as a result of this bit, the dialog doesnt paint anything inside the group box.
Removing the WS_CLIPCHILDREN style bit from the dialog works sort of. The remaining (lesser) problem is an inordinate amount of flashing during resizing not the group boxes themselves, but their contained controls.
Style Bits to the Rescue
How, then, to get rid of the flashing? After removing the WS_CLIPCHILDREN style bit from the dialog, I added the WS_EX_TRANSPARENT style bit to the group boxes (see Example 1). A window created with the WS_EX_TRANSPARENT style receives WM_PAINT messages only after all sibling windows beneath it have been updated not really our problem here, but for some reason, I felt it worth a try. The problem was now worse; not only did the contained controls flash, but the group boxes themselves joined the flashing fun. But then I reapplied the WS_CLIPCHILDREN style to the dialog, and amazingly things were now much better. Not perfect, because the group boxes still flash, but the other controls are okay, and the overall feel is acceptable.
Whats going on here? Apparently, the WS_EX_TRANSPARENT style forces the parent to repaint underneath the group box, child clipping or no child clipping, but the parent still clips to the other (non-group-box) children. This behavior is undocumented as far as I can tell.
To sum up: Apply the WS_EX_TRANSPARENT style to group boxes; apply the WS_CLIPCHILDREN style to dialogs.
Having gotten this far, I decided to check out the tab control while I was at it after all, the tab control also has a transparent hole in the middle. Table 1 shows the results of my experiment, which just goes to show that this transparency business really is tricky; its not just random clumsiness on Microsofts part. The good news is that group boxes and tab controls prefer the same combination of window styles, even though their behaviors are slightly different. (The tab control never makes the mess in Figure 1, for example. The tab controls messes are equally bad, but different.)
Philosophy Corner
All this brouhaha over some apparently simple style bits illustrates how hard it is to create a windowing system that lets widgets, menus, windows and devices work smoothly together. Even in its umpteenth release, Windows has glitches like this one, so its no wonder that so-called window-less windowing systems (think ActiveX or Java) abound with problems.
Netscape beautifully illustrates the magnitude of the problem by reimplementing every single Windows control for version 6 of its browser. When a standard check box has the keyboard focus you can toggle the checkmark with the spacebar. Keeping the spacebar depressed does not activate any form of auto-repeat. Not so with Netscapes check box: Keeping the spacebar depressed does activate auto-repeat, causing the checkmark to flash on and off.
Certainly this particular problem is not serious, but the two check boxes are different, and Microsofts original has the better behavior. Ill bet that Netscape didnt even consider the issue; theres a free Windows Developer T-shirt waiting for the first reader who can convince me otherwise.
Petter Hesselberg is a Partner with Accentures Oslo office. Hes been programming Windows for the past thirteen years and is the author of the book Programming Industrial Strength Windows. He can be reached through http://pethesse.home.online.no.