http://bugs.winehq.org/show_bug.cgi?id=4009
------- Additional Comments From madewokherd@gmail.com 2006-04-06 14:23 ------- Created an attachment (id=2583) --> (http://bugs.winehq.org/attachment.cgi?id=2583&action=view) WINEDEBUG=+win log
Ok, it finally occurred to me to get a +win log, and I'm pretty sure I understand this now. No more guesswork.
The window passed to SetCooperativeLevel is called "Worms Armageddon" (0x10028). While the menu is showing, this window has some child windows representing controls on the screen. The heiarchy looks something like this:
0x10028 "Worms Armageddon" `-0x10023 "#32770" |- Single player button |- Hotseat game button |- Quit button `- etc.
The immediate child is destroyed and a new one is created every time the "layout" of the menu changes. Its size is always the same as Worms Armageddon's size, and it always obscures the entire window.
Someone (I don't know if it's the game or Wine doing this) appears to check which window the mouse is on whenever it moves. The result is always a child of Worms Armageddon.
I tried the demo of Diablo (see bug 2082), and it follows the same pattern: a main window passed to SetCooperativeLevel, a child window the same size, and child controls on that window. It also has the same problem, fixed by the same hack (yay Byte).
Since the hwnds appear to be the same every time, I tried modifying ddraw to draw to 0x10023, the immediate child of Worms Armageddon. The menu showed up fine (this is a little odd; I expected only part of the menu to show up and part of it to be obscured by that window's children).
So the problem seems to be that ddraw is drawing to the area of the SCL window that isn't obscured by children. I don't know why it's doing this. It already uses a call to GetDCEx without the DCX_CLIPCHILDREN flag. I also don't know how to make a test for this or correct the problem.