[PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter.

[Alexandre Julliard]

Christopher Thielen <cthielen at gmail.com> writes:

> Thank you Alexandre, you're absolutely right.
>
> Below is a further analysis on toolbar, trackbar, and button:
>
> Toolbar: Assumes a WM_CAPTURECHANGED messages implies a toolbar button
> is no longer pressed. The proposed patch would therefore break
> existing behavior if and only if the toolbar code also calls
> SetCapture() on itself while it already has capture. Toolbar currently
> only calls SetCapture() in the case of a LButtonDown on
> itself. Notably, another piece of code could in theory call
> SetCapture() on the toolbar's hWnd as well.
>
> Trackbar: Assumes a WM_CAPTURECHANGED message implies a TB_ENDTRACK,
> again, only breaking current behavior if trackbar calls SetCapture()
> while it already has mouse capture. Like Toolbar above, Trackbar only
> calls SetCapture() if it receives a LButtonDown. Again, another piece
> of code could in theory call SetCapture() and pass the trackbar's hWnd
> even when it already has mouse focus.
>
> dlls/user32/button.c: Causes a button with mouse focus and
> BUTTON_BTNPRESSED to lose its highlighted state as documented at
> https://msdn.microsoft.com/en-us/library/aa931528.aspx. Like the two
> cases above, button would need to call SetCapture() on itself for this
> patch's behavioral changes to be relevant. Button calls SetCapture()
> on KEYDOWN, LBUTTONDBCLK, and LBUTTONDOWN.
>
> I would be grateful if a seasoned Wine developer could chime in as to
> whether or not the above scenarios are possible, or what further
> research they would recommend. Otherwise, one safe course of action
> could be to emulate the existing Wine behavior of requiring the newly
> mouse-focused hWnds to be different from the existing hWnd in order
> for these three code paths to run (thus maintaining the current
> behavior for these specific cases). That would correct the
> SetCapture() behavior, fix the documented bug, and prevent any side
> effects in this code, though I'd prefer to better understand the above
> three code paths than rely on that idea.

As you said, other code may call SetCapture, or the controls themselves
could be modified to call it at some later date. So the window procs
should be updated to verify that the capture has really changed before
proceeding.

-- 
Alexandre Julliard
julliard at winehq.org