[bug 1858] WM_MOUSEACTIVATE processing

[Ann & Jason Edmeades]

This bug reported a problem where tab switching didn't occur. I debugged
this application through to identifying that when the tab representing the
MDI child window is clicked on, a WM_MOUSEACTIVATE message goes to the MDI
child window, working up the window stack until the main window passes it to
the DefWindowProc. Under windows, ACTIVATE was returned whereas under wine
it wasn't. 

SPY output from windows:
<04014> 00200344 S WM_MOUSEACTIVATE hwndTopLevel:001F038E nHittest:HTNOWHERE
uMsg:WM_NULL [wParam:001F038E lParam:00000000]
<04015> 000C032C S WM_MOUSEACTIVATE hwndTopLevel:001F038E nHittest:HTNOWHERE
uMsg:WM_NULL [wParam:001F038E lParam:00000000]
<04016> 001F038E S WM_MOUSEACTIVATE hwndTopLevel:001F038E nHittest:HTNOWHERE
uMsg:WM_NULL [wParam:001F038E lParam:00000000]
<04017> 001F038E R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
[lResult:00000001]

Under wine, our defwinproc was not returning MA_ACTIVATE for HTNOWHERE
(0x0000), and a simple change confirmed that returning that did indeed fix
the problem. That leaves the question as to whether the change is right.

I've attached a patch plus simple modified the tests to ensure that
MA_ACTIVATE is correct. Please let me know if there are any problems with
this one - I don't like touching the defwinproc!

Changelog

Always return MA_ACTIVATE for WM_MOUSEACTIVATE in the DefWindowProc

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1858.patch
Type: application/octet-stream
Size: 3189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20050924/665d2a94/1858.obj