[PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter.
Christopher Thielen
cthielen at gmail.com
Fri Jan 15 22:26:30 CST 2016
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.
Thank you again to anyone who can offer any guidance.
On 01/14/2016 03:02 AM, Alexandre Julliard wrote:
> Christopher Thielen <cthielen at gmail.com> writes:
>
>> dlls/comctl32/toolbar.c: case WM_CAPTURECHANGED:
>>
>> Probably fine? Appears to be a ToolbarProc translating window messages into toolbar-based equivalents.
>
> That's too superficial, you need to look into what it's doing with the
> message. In this case it's clearly assuming that capture is lost, which
> wouldn't be the case with your change. The same thing probably applies
> to other message handlers.
>
More information about the wine-devel
mailing list