[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: comctl32/listview: fix mouse message sequences
From:       Daniel Jelinski <djelinski1 () gmail ! com>
Date:       2013-02-26 5:50:58
Message-ID: CAMrH03Jt2hpLW4zWOcSnGEOYar1YRHrEEKexa6u4wFkn3Df3Gg () mail ! gmail ! com
[Download RAW message or body]

2013/2/25 Nikolay Sivov <bunglehead@gmail.com>:
> On 2/24/2013 17:52, Daniel Jelinski wrote:
>>
>> 2013/2/24 Nikolay Sivov <bunglehead@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.


[prev in list] [next in list] [prev in thread] [next in thread]