Re: comctl32/listview: fix mouse message sequences

[Nikolay Sivov]

On 2/24/2013 01:33, Daniel Jelinski wrote:
> @@ -10178,6 +10139,19 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, IN
>   if (infoPtr->dwLvExStyle & LVS_EX_ONECLICKACTIVATE)
>       if(lvHitTestInfo.iItem != -1) notify_itemactivate(infoPtr,&lvHitTestInfo);
> - if (LISTVIEW_TrackMouse(infoPtr, pt))
> - {
> -
>    NMLISTVIEW nmlv;
> -
> -
>    ZeroMemory(&nmlv, sizeof(nmlv));
> -
>    nmlv.iItem = lvHitTestInfo.iItem;
> -
>    nmlv.ptAction = infoPtr->ptClickPos;
> -
> -
>    notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv);
> -
>    infoPtr->bDragging = TRUE;
> - }
> - else
> -
>    LISTVIEW_LButtonUp(infoPtr,0,x,y);

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?

comctl32/listview: fix mouse message sequences

[Daniel Jelinski]

2013/2/24 Nikolay Sivov :
> 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), so calling LButtonUp
here is almost exactly what happened before. I'm not sure if inlining
the call would help here.
Regards,
Daniel

comctl32/listview: fix mouse message sequences

[Nikolay Sivov]

On 2/24/2013 17:52, Daniel Jelinski wrote:
> 2013/2/24 Nikolay Sivov :
> > 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?
> so calling LButtonUp
> here is almost exactly what happened before. I'm not sure if inlining
> the call would help here.
> Regards,
> Daniel

comctl32/listview: fix mouse message sequences

[Daniel Jelinski]

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