[Lazarus] TListview event order and drag bug [[Re: We are planning the next release: Lazarus 2.0.8]]

[Martin Frb]

On 03/04/2020 11:05, Juha Manninen via lazarus wrote:
> On Fri, Apr 3, 2020 at 11:35 AM Rolf Wetjen via lazarus 
> <lazarus at lists.lazarus-ide.org <mailto:lazarus at lists.lazarus-ide.org>> 
> wrote:
>
>     I wanted to ask for https://bugs.freepascal.org/view.php?id=35362
>     and https://bugs.freepascal.org/view.php?id=36798.
>
>
> OK, that makes more sense. :)
> Issue #35362 is a regression. If your patch works it surely should be 
> applied and merged to 2.0.8 branch.
> Apparently Michl is not active right now so I assigned the issue to 
> Martin.
> I myself don't have a Windows now. I am setting up Lazarus under Wine 
> in my new super-computer (!) and then I can test Windows patches, too.
> Wine has improved steadily and is very good nowadays.

I did some tests.  (more pending / some assumptions below)

The problem with the patch is, that the LCL events (and the On... 
events) will then all be called on mouse up.
That is, the mouse down event, will be hold back, until the button is 
released.

As far as I can see the problem is, that the WindProc, first calls the 
DefaultWindProc, which (some tests pending) does not return until the 
mouse up occurs.
https://docs.microsoft.com/en-us/windows/win32/controls/listview-message-processing 
=> it goes into a modal loop....

So If I am right, I guess this listview needs its own windproc, and must 
trigger the LCL (DeliverMessage) for WMMouseDown before calling DefaultProc.

Downside: the OnMouseDownEvent is called before the OS widget even 
knows. So maybe some state info will be different......

But as far as I see it, its either that, or defer to mouse up.

-------------------------
In either case, I consider the changes to big for being merged.

1) Defer the event: that is a major behaviour change, needs documented
2) own event proc. That needs a lot of testing, as it is easy to 
overlook stuff and break it. (Not to say it needs to be implemented).


*****  I think ***
  the immediate DeliverMessage is the better approach. (Despite the 
possible not yet updated widget)

But it may turn out to have downsides.

So anyone else any preferences?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200404/73177dd1/attachment.html>