WS_EX_COMPOSITED style (double buffering) problems

Hello,

I have two problems with this style:

1. If a dialog box is given this style during the WM_INITDIALOG message (i.e. as the dialog is being created, before it is displayed), AND if the dialog box is initially invisible, then my program crashes immediately. It seems like the style is attempting to get the dialog box and all of its controls to draw themselves in the secondary buffer, but this attempt continually fails since they refuse to draw themselves, since their update regions are empty. It is like it wants them to draw, so it tried to send them WM_PAINT messages, but they refuse it each time.

Has anyone experienced this behaviour? I can resolve the situation by making the dialog box initially visible OR by not giving it the WS_EX_COMPOSITED style during WM_INITDIALOG. If I give it the style afterwards, all is fine. Strange...

2. The WS_EX_COMPOSITED style appears to make the 'x' close button not react visibly to the user's actions, even though it still works. So, the button does not depressed when the user clicks it, but when the user let's go, it sends the appropriate message.

Any input / ideas are appreciated.

1. I don't get this behaviour. I tried both modal and modeless dialogs. In both cases the application of the extended style is successful using SetWindowLong/SetWindowLongPtr in WM_INITDIALOG.

Have you tried applying the WS_EX_COMPOSITED extended style by editing the resource script itself?

2. I observed this behaviour also but can't currently offer a solution other than to note that it's probably a glitch with the windows implementation.

Sorry I can't be of more help than that. :(

Ken Fitlike, thanks for the reply.

1. I created a very small test program to test this out, and now I find that setting the extended style within WM_INITDIALOG is completely fine, even if the dialog is initially invisible. Apparently, something else is going on in my other application...

2. Yup, it must be a glitch...

Thanks for your help.