SetForegroundWindow() from WM_ACTIVATE broken

Jon Griffiths jon_p_griffiths at yahoo.com
Thu Nov 25 11:55:30 CST 2004


Hi,

More on this problem ... here what happens under native when the back
window is clicked:

Order of trace below is (msg, hwnd, wparam,lparam)

The app is started, click on the client area of the background window
WM_MOUSEACTIVATE     back  001203aa 02010001 (MA_ACTIVATE)

Front window is told its going inactive
WM_NCACTIVATE        front 00000000 back
WM_ACTIVATE          front WA_INACTIVE back

SetWindowPos() is called to raise back window to the front of the
zorder, nc client and background told to paint
WM_WINDOWPOSCHANGING back  00000000 0012fea8
WM_NCPAINT           back  00000001 00000000
WM_ERASEBKGND        back  0101005a 00000000
WM_WINDOWPOSCHANGED  back  00000000 0012fea8

Back window is told its going active
WM_NCACTIVATE        back  00000001 front
WM_ACTIVATE          back  WA_CLICKACTIVE front

Now the back window calls SetForegroundWindow(front), within its
WM_ACTIVATE handler

 Back window is told its going inactive
 WM_NCACTIVATE        back  00000000 front
 WM_ACTIVATE          back  00000000 front

 Front window brought to the top of the z-order w/SetWindowPos
 WM_WINDOWPOSCHANGING front 00000000 0012fd0c
 WM_NCPAINT           front 00000001 00000000
 WM_ERASEBKGND        front 0101005a 00000000
 WM_WINDOWPOSCHANGED  front 00000000 0012fd0c

 Front window is told its going active
 WM_NCACTIVATE        front 00000001 back
 WM_ACTIVATE          front 00000001 back

Under wine the message stream doesn't have the SetWindowPos calls,
and there are several hundred activate/ncactivate messages, ending
with the back window in the front of the z-order, activated with the
focus.

Looking at the logic in dlls/user/focus.c, in set_active_window(), it
seems that SetWindowPos() was not being called because the windows
both have the WS_EX_MANAGED style set. Commenting out the line

if (!(GetWindowLongW( hwnd, GWL_EXSTYLE ) & WS_EX_MANAGED))

Caused the front window to remain on top after clicking on the back
window, as desired. However it did then not get the focus as it
should, and titlebar clicks and double clicks in the client area
still allow the back window to rise to the top of the z-order.

I added a test to check if the window is the foreground window (i.e.
that some other window hasn't been set in the interim) before setting
the focus. This means my test app now appears to work just like
native.

The attached patch makes both of these changes. I'd be interested in
any comments regarding whether the above is correct.

Cheers,
Jon


=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

jon_p_griffiths at yahoo.com


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: focus.diff
Type: application/octet-stream
Size: 883 bytes
Desc: focus.diff
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20041125/d30ea5ee/focus.obj


More information about the wine-devel mailing list