[Bug 10543] worms armageddon crashes when clicking the menu

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10543





--- Comment #6 from Vincent Povirk <madewokherd at gmail.com>  2007-12-06 14:51:14 ---
I used an autohotkey script to log the series of activated windows on wine
0.9.48 and on a friend's windows machine. We each went to the hotseat game
screen and the options subscreen and then quit by clicking the quit buttons. It
showed that T17 was activated 4 times on wine 0.9.48 and not at all on windows.

Unfortunately, the script has a race condition: if the focus changes twice fast
enough, it will only see the second change. To confirm my results, we used
another script that waited specifically for T17 to activate (this does not have
a race condition unless AHK's implementation of WinWaitActive does) and logged
the same things. It logged 5 lines on wine 0.9.48 (the last one was 0x20034 - 
-  activated, the others did show T17's title) and 1 on windows (0xe0616 -  -
#32770 activated). So I know T17 was activated at least once on windows, but I
don't know when. I believe it happened only once, but I can't prove it.

This (and bug 8101 and the fact that a WA developer expected the focus to go to
a parent of a dialog when the dialog was ended) leads me to believe that the WA
frontend only worked in the past by coincidence and that
WINPOS_ActivateOtherWindow was never correct in situations WA creates. I will
need to research WINPOS_ActivateOtherWindow--find out why it exists, what it's
supposed to do, why we expect the functions using it to work the same way--and
create some tests of how dialog windows that are also child windows (which is
the situation I believe WA creates that causes problems for wine) work.

I will attach my first script and the logs it generated.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.