Missing WM_CAPTURECHANGED message

Christopher Thielen cthielen at gmail.com
Wed Nov 18 20:59:15 CST 2015


Thanks Ken. I do have a test in mind that I'll submit with my patch but 
first ... do all the tests in dlls/user32/tests/ pass normally?

I've got the latest git as of 7f6634b2bd916b530e30ef8a850fefbc0dbdf687 
(Nov 16 22:36 GMT+1) and I receive the following when I run 'make test' 
in that directory (this is without my patch):

../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p 
user32_test.exe.so win && touch win.ok
fixme:msg:pack_message msg 138 (WM_CTLCOLORSTATIC) not supported yet
err:win:DefWindowProcW called for other process window 0x4005c
fixme:msg:pack_message msg 135 (WM_CTLCOLORBTN) not supported yet
fixme:msg:pack_message msg 135 (WM_CTLCOLORBTN) not supported yet
fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported 
on other process window 0x200c8
fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported 
on other process window 0x200c8
fixme:msg:pack_message msg 135 (WM_CTLCOLORBTN) not supported yet
fixme:msg:pack_message msg 135 (WM_CTLCOLORBTN) not supported yet
fixme:msg:pack_message msg 135 (WM_CTLCOLORBTN) not supported yet
fixme:win:FlashWindowEx 0x33fbfc - semi-stub
fixme:win:FlashWindowEx 0x33fbfc - semi-stub
fixme:win:FlashWindowEx 0x33fbfc - semi-stub
win.c:2337: Test succeeded inside todo block: GetActiveWindow() = 0x50056
win.c:2337: Test succeeded inside todo block: GetForegroundWindow() = 
0x50056
win.c:2337: Test succeeded inside todo block: GetFocus() = 0x50056
win.c:2561: Test failed: 0x50056: expected prev (nil), got 0x1d00cc
win.c:2569: Test failed: 0xa00a8: expected next 0x50056, got 0x1d00cc
win.c:2574: Test failed: 0x50056: expected prev (nil), got 0x1d00cc
win.c:2583: Test failed: 0x50056: expected prev 0x9004c, got 0x1d00cc
win.c:2584: Test failed: 0x9004c: expected next 0x50056, got 0x1d00cc
win.c:2593: Test failed: 0x50056: expected prev 0x9004c, got 0x1d00cc
win.c:2594: Test failed: 0x9004c: expected next 0x50056, got 0x1d00cc
win.c:2604: Test failed: 0x50056: expected prev 0x9004c, got 0x1d00cc
win.c:2605: Test failed: 0x9004c: expected next 0x50056, got 0x1d00cc
win.c:2614: Test failed: 0x50056: expected prev 0xa00a8, got 0x1d00cc
win.c:2615: Test failed: 0xa00a8: expected next 0x50056, got 0x1d00cc
win.c:2639: Test failed: 0x50056: expected prev 0xa00a8, got 0x1d00cc
win.c:2640: Test failed: 0xa00a8: expected next 0x50056, got 0x1d00cc
win.c:2561: Test failed: 0x50056: expected prev (nil), got 0x1d00cc
win.c:2569: Test failed: 0xb00a8: expected next 0x50056, got 0x1d00cc
win.c:2574: Test failed: 0x50056: expected prev (nil), got 0x1d00cc
win.c:2583: Test failed: 0x50056: expected prev 0xf00aa, got 0x1d00cc
win.c:2584: Test failed: 0xf00aa: expected next 0x50056, got 0x1d00cc
win.c:2593: Test failed: 0x50056: expected prev 0xf00aa, got 0x1d00cc
win.c:2594: Test failed: 0xf00aa: expected next 0x50056, got 0x1d00cc
win.c:2604: Test failed: 0x50056: expected prev 0xf00aa, got 0x1d00cc
win.c:2605: Test failed: 0xf00aa: expected next 0x50056, got 0x1d00cc
win.c:2614: Test failed: 0x50056: expected prev 0xb00a8, got 0x1d00cc
win.c:2615: Test failed: 0xb00a8: expected next 0x50056, got 0x1d00cc
win.c:2639: Test failed: 0x50056: expected prev 0xb00a8, got 0x1d00cc
win.c:2640: Test failed: 0xb00a8: expected next 0x50056, got 0x1d00cc
win.c:5851: Test failed: expected a nonempty window text
win.c:5852: Test failed: got wrong window text 'Default - Wine desktop'
win.c:2983: Test succeeded inside todo block: Expected active window 
0x8200b0, got 0x8200b0.
win.c:2984: Test succeeded inside todo block: Expected focus window 
0x8200b0, got 0x8200b0.
Makefile:621: recipe for target 'win.ok' failed
make: *** [win.ok] Error 33

On 11/15/2015 11:09 PM, Ken Thomases wrote:
> On Nov 15, 2015, at 9:40 PM, Christopher Thielen <cthielen at gmail.com> wrote:
>>
>> I figured out this behavior. It seems if one calls SetCapture() twice it will cause Windows to send a WM_CAPTURECHANGED message to the same window given as the parameter of SetCapture(). Wine does not currently follow this behavior.
>>
>> The following patch fixes the behavior, though I'm not sure if it's the right way to fix the issue as I don't know why the original author(s) made the removed check in the first place. Does anyone have any ideas?
>>
>> (Generated against wine.git on 11/15/15 at 19:28 PST):
>>
>> diff --git a/dlls/user32/input.c b/dlls/user32/input.c
>> index 40e35a9..63fae67 100644
>> --- a/dlls/user32/input.c
>> +++ b/dlls/user32/input.c
>> @@ -108,7 +108,7 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret )
>>      {
>>          USER_Driver->pSetCapture( hwnd, gui_flags );
>>
>> -        if (previous && previous != hwnd)
>> +        if (previous)
>>              SendMessageW( previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd );
>>
>>          if (prev_ret) *prev_ret = previous;
>
> Have you run the user32 tests with this change in place?  Does it break any tests?
>
> Can you write a test for the behavior that you're seeing?  Does that test pass on the testbot's Windows VMs?
>
> The history of this code is that it was consolidated from multiple similar code paths that all had that check against the previous and new windows being the same.  In particular, it's used by implicit captures, such as with menu tracking and window moving and resizing, as well as explicit captures.  You'd want to be sure that those other paths don't break as a result of your change.
>
> Regards,
> Ken
>



More information about the wine-devel mailing list