Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Resizable Dialogs Revisited


January 2002/User Interface Programming

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 Martin’s 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 doesn’t 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.

What’s 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; it’s not just random clumsiness on Microsoft’s 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 control’s 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 it’s 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 Netscape’s 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 Microsoft’s original has the better behavior. I’ll bet that Netscape didn’t even consider the issue; there’s a free Windows Developer T-shirt waiting for the first reader who can convince me otherwise.


Petter Hesselberg is a Partner with Accenture’s Oslo office. He’s 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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.