comctl32/listview: fix mouse message sequences

[Daniel Jelinski]

2013/2/25 Nikolay Sivov <bunglehead at gmail.com>:
> On 2/24/2013 17:52, Daniel Jelinski wrote:
>>
>> 2013/2/24 Nikolay Sivov <bunglehead at gmail.com>:
>>>
>>> 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:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774734%28v=vs.85%29.aspx
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.