At 11:42 PM 9/15/00 +0000, you wrote:
>an InstallShield installer does a SetParent() on a dialog that has been
>created within another dialog, with this dialog being its "owner".
>
>Directly after that SetParent, it does a GetParent which fails:
> if(!(wndPtr = WIN_FindWndPtr(hwnd))) return 0;
> if ((!(wndPtr->dwStyle & (WS_POPUP|WS_CHILD))))
> goto end;
>--> 0.
>
>(reason: no WS_CHILD style)
>The program does many GetParent(), BTW.
>
>I couldn't see any location where this window got set its WS_CHILD style
>inside SetParent (do a grep on WS_CHILD in the Wine tree and you'll see).
>
>By doing
> pWndOldParent = WIN_LockWndPtr((*wndPtr->pDriver->pSetParent)(wndPtr,
>pWndNewParent));
>
>+ wndPtr->dwStyle |= WS_CHILD;
>
>in SetParent, the installer proceeded.
>Now it updated the progress bar that it was supposed to update
>and installed -- well, not quite; it bailed out somewhat later :-\
>
>At first I thought that this might be a valid fix, but it isn't:
>MSDN indicates that SetParent doesn't touch the WS_CHILD flag.
Yes, the MSDN is very clear about this; as I trust the MSDN in
the same way I trust a politician's promise, I even wrote a test app
to check on this and surprise ! the MSDN is right. Reparenting a
non child window to another window does not set the WS_CHILD
style. That should mean IMHO that the WS_CHILD style test in
GetParent is wrong. I have no idea how Windows does it. I
remember dimly having seen in the big garbage heap that
windows (or what is only some controls only ? I'm not sure) had
a field to keep the original parent, the one set at window creation.
Maybe if this feature was added it could be possible to have a better test
in GetParent. Using an internal WS_CHILD style could be a way
too.
Gerard
