Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg

[Dmitry Timoshkov]

"James Hawkins" <truiken(a)gmail.com> wrote:
> You were right about having the NM_CLICK msg sent in
> LISTVIEW_LButtonUp, and the problem was that a WM_LBUTTONUP msg was
> never sent.  This fixes the problem where you had to double click an
> item in the drives list to select it.
>
> Changelog
> * Make sure a WM_LBUTTONUP msg is dispatched after tracking a WM_LBUTTONDOWN msg
> --- dlls/comctl32/listview.c 6 May 2005 15:44:32 -0000 1.409
> +++ dlls/comctl32/listview.c 12 May 2005 05:04:06 -0000
> @@ -7948,6 +7948,9 @@ static LRESULT LISTVIEW_TrackMouse(LISTV
>       else if (msg.message >= WM_LBUTTONDOWN &&
>         msg.message <= WM_RBUTTONDBLCLK)
>       {
> +            if (msg.message == WM_LBUTTONUP)
> +                DispatchMessageW(&msg);

Why WM_LBUTTONUP should be different from other kinds of messages?
I.e. why all messages could not be passed to DispatchMessage? What
if just move DispatchMessageW call right right after PeekMessageW?

-- 
Dmitry.

comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg

[Alexandre Julliard]

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes:
> Why WM_LBUTTONUP should be different from other kinds of messages?
> I.e. why all messages could not be passed to DispatchMessage? What
> if just move DispatchMessageW call right right after PeekMessageW?

Actually the whole function looks very suspicious, especially the busy
wait for a mouse message. I think this needs to be redone differently.

-- 
Alexandre Julliard
julliard(a)winehq.org