Re: comctl32: Ensure listview control has focus when marquee dragging

[Nikolay Sivov]

Owen Rudge wrote:
> This patch fixes an issue whereby a selection marquee would not 
> function correctly when the listview hadn't first been clicked on.
>
> ---
>  dlls/comctl32/listview.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> @@ -3631,6 +3631,9 @@ static LRESULT LISTVIEW_MouseMove(LISTVIEW_INFO *infoPtr, WORD fwKeys, INT x, IN
>              LVITEMW item;
>              ITERATOR i;
>
> +            if (!infoPtr->bFocus)
> +                SetFocus(infoPtr->hwndSelf);
> +
> Hi, Owen.

This doesn't look right. Try with ControlSpy and you'll see WM_SETFOCUS 
sent just after LButton pressed on
client area (not on item, that's important). LButtonUp event used to set 
focus item was under mouse pointer and it's
released without any mouse movements (or maybe drag threshold doesn't 
count).

comctl32: Ensure listview control has focus when marquee dragging

[Owen Rudge]

Hi Nikolay,
> This doesn't look right. Try with ControlSpy and you'll see WM_SETFOCUS 
> sent just after LButton pressed on
> client area (not on item, that's important). LButtonUp event used to set 
> focus item was under mouse pointer and it's
> released without any mouse movements (or maybe drag threshold doesn't 
> count).

I've just tested this with ControlSpy on wine with my patch, NM_SETFOCUS 
is sent after LButton is released, when clicking on the client area. It 
is also sent when clicking on an item and releasing the pointer without 
any mouse movements, as you say. Possibly I'm misunderstanding what 
you're saying here, but I'm not sure I see where the problem is? 
Behaviour is, as far as I can tell, identical with my patch and without 
it, with the exception of course of the NM_SETFOCUS if the window does 
not already have focus.

Cheers,

-- 
Owen Rudge
http://www.owenrudge.net/

comctl32: Ensure listview control has focus when marquee dragging

[Nikolay Sivov]

Owen Rudge wrote:
> Hi Nikolay,
>
>> This doesn't look right. Try with ControlSpy and you'll see 
>> WM_SETFOCUS sent just after LButton pressed on
>> client area (not on item, that's important). LButtonUp event used to 
>> set focus item was under mouse pointer and it's
>> released without any mouse movements (or maybe drag threshold doesn't 
>> count).
>
> I've just tested this with ControlSpy on wine with my patch, 
> NM_SETFOCUS is sent after LButton is released, when clicking on the 
> client area.
Exactly, and this isn't a case on native. It is sent on LButtonDown is 
pressed not-on-item. Also you may want to look at message list for 
ListView window (on wine it doesn't work and I mean native system here) 
- after SetFocus() ListView get WM_SETFOCUS, it allows to determine when 
we should to call SetFocus(), I'm not sure maybe NM_SETFOCUS is an 
always forwarded WM_SETFOCUS...
> It is also sent when clicking on an item and releasing the pointer 
> without any mouse movements, as you say. Possibly I'm misunderstanding 
> what you're saying here, but I'm not sure I see where the problem is? 
> Behaviour is, as far as I can tell, identical with my patch and 
> without it, with the exception of course of the NM_SETFOCUS if the 
> window does not already have focus.
This isn't a problem actually, it's difference in notification sequence. 
On native focusing never depends on Mousemove and you're adding this 
dependency.
>
> Cheers,
>