Hi
I've found a really simple application with exhibits strange behaviour. I'm no
Win**ws programmer, so I don't know if the code is ok, but at least it seems
to be. I wrote it while trying to debug some problems with a resource editor
called Resource Hacker 2.2.1. I'm using the 20001026 release of Wine.
The attached (6k) archive includes source and exe of a small program which
opens a window and a dialog and calls SetParent() to make the dialog a child
of the window. For debugging purposes, clicking in the main window flips the
dialog on/off. Note that the dialog already was a child from the beginning,
so one would think that the SetParent() call shouldn't change much?
Problems under Wine:
- the dialog can't be dragged.
- the dialog isn't painted properly in unmanaged/managed modes. Desktop paints
ok.
Observations:
Calling SetParent() makes the dialog "clipped into" the main window. It
behaves more or less like WS_CHILD would get set IMHO, but GetWindowLong
returns nothing special, so no flags apparently change in real win95.
Setting WS_CHILD in SetParent() appears to fix the dragging problem, but
I'm not sure if it is the right thing to do. I wonder how win95 does this.
--- win.c_bak Mon Oct 30 23:54:01 2000
+++ win.c Thu Nov 2 01:08:21 2000
@@ -2408,6 +2408,7 @@
if(!(wndPtr = WIN_FindWndPtr(hwndChild))) return 0;
dwStyle = wndPtr->dwStyle;
+ wndPtr->dwStyle |= WS_CHILD; /* FIXME: Hack */
pWndNewParent = hwndNewParent ? WIN_FindWndPtr(hwndNewParent)
: WIN_LockWndPtr(pWndDesktop);
I really have no clues regarding the painting problems, but I have a feeling
that the same bug causes problems with the playlist editor in my rather old
version of Winamp as well. That one is also done using a dialog.
Any input is appreciated.
Nicke
--
-[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
ZIP archive
