"Funny" window visibility problems!

[JensE]

Hi, I am using Win32API to create a window based editor for WinME.

The problem recently occured is that moved or hidden windows are still visible:

After creating my main window, I create a child groupbox which has no WS_VISIBLE style.
Then I create some child windows of that groupbox, they've got the WS_VISIBLE flag set.
When I show the whole groupbox, all child windows also show up correctly.

But if I then hide one particular child window of that groupbox (with ShowWindow(hWindow, SW_HIDE)), it's still visible. Even the face of such a child window button is still displayed, but you cannot click on it and no tooltip is shown.
The same problem takes effect with MoveWindow() or other position changing functions: The child windows are visible in their new AND their old locations after beeing moved!

Note: The parent groupbox is subclassed, can this be a reason?

[Marc G]

It seems to me that it's some kind of a refresh issue.
Try to call Invalidate(parentHWND) to refresh the parent.

[JensE]

I used InvalidateRect(hParent, NULL, true) after showing/hiding the parents of the windows the problem concerns, but this doesn't help, UpdateWindow(), RedrawWindow() etc. don't work, too.

What about subclassing of the parent groupboxes? If I don't apply a subclass proc, the problem still remains. Thus this could'nt be the problem!?

[Marc G]

mmm, strange.

When you move another window (example notepad) ontop of your groupbox and then bring your window with your group box back to the front, does this gets rid of the "ghost" buttons?

Have you set the WS_EX_TRANSPARENT style on your groupbox? If so, try too remove it and see if that helps.

[JensE]

Yes, the "ghost" windows disappear if I move another window above it :confused:, but I didn't use the WS_EX_TOPMOST style for the groupboxes.
Does this indicate that WM_PAINT is not correctly processed by windows standard message processing? Or is it just a WinME problem?

Very confusing, is there something else essential I forgot? :(

[Marc G]

mmm, just a few suggestions:

Have you set the WS_EX_TRANSPARENT style on your groupbox? If so, try too remove it and see if that helps.
Have you set the WS_CLIPCHILDREN style on your groupbox? If so, try too remove this too and see if it changes anything.

[JensE]

No, I didn't use this styles with my groupboxes!

[Marc G]

Really weird...

If it's possible for you to post a little sample app that demonstrates the problem, i can take a look at it.

Otherwise, you said you subclassed the groupbox. Which messages to you process for you groupbox? Perhaps you can post your message processing function for you groupbox?

[JensE]

Sure, I can: Here is the coding dealing with the groupbox:


In an init function:

WNDPROC pFOldSel = (WNDPROC) SetWindowLong
(hGR_Selection, GWL_WNDPROC, DWORD (hGR_SelectProc));

SetProp(hGR_Selection, "OldProc", (HANDLE) pFOldSel);

This sets the new subclass proc, saves the old in pFOldSel and provides it to that proc as a property.

Here is the subclass proc of the groupbox:

LRESULT hGR_SelectProc(HWND Hwnd, UINT Message,
WPARAM WParam, LPARAM LParam) {

WNDPROC pFOld = (WNDPROC) GetProp(Hwnd, "OldProc");

switch (Message)

{ case WM_COMMAND:

{ if (HIWORD(WParam) == BN_CLICKED)

{ ..... } }

break;

default: break; }

return CallWindowProc(pFOld, Hwnd, Message, WParam,
LParam); }

Here I fetch the old proc, process only clicking on buttons and in the end I call the old proc.

It seems to me this must be the reason somehow, 'cause of the following points:

- 1) I subclassed over 8 groupboxes;
- 2) The problem occurs only in subclassed child windows, not
in any other child windows;
- 3) Some of the child windows of the subclassed groupboxes
are also subclassed.

Maybe this extravagant use of subclassing is one reason?