comctl32/listview: fix mouse message sequences

Daniel Jelinski djelinski1 at
Mon Feb 25 23:50:58 CST 2013

2013/2/25 Nikolay Sivov <bunglehead at>:
> On 2/24/2013 17:52, Daniel Jelinski wrote:
>> 2013/2/24 Nikolay Sivov <bunglehead at>:
>>> This doesn't look very clean. I mean invoking *up handler from a *down
>>> one.
>>> Is this something that could be resolved with message loop like rbutton
>>> dragging was fixed?
>> TrackMouse contains the message loop. It returns FALSE when it
>> receives LBUTTONUP (or any other button message),
> Okay, so why not let corresponding message handler to process it normally?

Short answer: because that's how native behaves. They don't call
DispatchMessage on button messages received in message loop, so
neither do we.

According to this MSDN page:
Listview window procedure does not handle MOUSEMOVE and *BUTTONUP
messages. My experience with +message logs seems to confirm that.
Every time when any action happens in response to *BUTTONUP, it is
contained in some kind of message loop.
My long term goal is to remove these handlers from wine's
implementation as well. I wanted to remove call to LISTVIEW_LButtonUp
from window proc already, but unfortunately marquee selection still
depends on it.

More information about the wine-devel mailing list