View Issue Details

IDProjectCategoryView StatusLast Update
0027189LazarusPatchpublic2020-04-19 00:32
ReporterMichl Assigned ToJuha Manninen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformWindowsOS7 
Product Version1.3 (SVN) 
Summary0027189: TListView OnMouseUp called twice
DescriptionIn TWin32WSCustomListView is a workaround, what isn't needed for Win7. So it has to be removed completly. If it is needed for other Windows versions (what I don't know) there should be a check.
Steps To Reproduceprocedure TForm1.ListView1MouseDown(Sender: TObject;
  Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
begin
  WriteLn('MouseDown ListView');
end;

procedure TForm1.ListView1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  WriteLn('MouseUp ListView');
end;

Or test the added minimal example.
Additional InformationThere is a discussion on German Lazarusforum: http://www.lazarusforum.de/viewtopic.php?f=19&t=8342

I've added two patches:
patch1 -> test Win7
patch2 -> remove workaround
Tagspatch
Fixed in Revisionr47557, r47558, r51471
LazTarget-
WidgetsetWin32/Win64
Attached Files

Relationships

related to 0033330 closedMichl Packages Mouse events do not fire properly when MultiSelect = True on TListView of win32/64 
related to 0033811 resolvedMartin Friebe Lazarus Listview: DragMode dmAutomatic does not function with Multiselect enabled 

Activities

Michl

2014-12-20 14:01

developer  

Michl

2014-12-20 14:01

developer  

patch1_win32wscustomlistview.inc.patch (625 bytes)   
Index: lcl/interfaces/win32/win32wscustomlistview.inc
===================================================================
--- lcl/interfaces/win32/win32wscustomlistview.inc	(revision 47221)
+++ lcl/interfaces/win32/win32wscustomlistview.inc	(working copy)
@@ -225,6 +225,7 @@
       case PNMHdr(LParam)^.code of
         NM_CLICK, NM_RCLICK:
         begin
+          if WindowsVersion = wv7 then Exit;
           // A listview doesn't get a WM_LBUTTONUP, WM_RBUTTONUP message,
           // because it keeps the message in its own event loop,
           // see msdn article about "Default List-View Message Processing"

Michl

2014-12-20 14:02

developer  

patch2_win32wscustomlistview.inc.patch (1,453 bytes)   
Index: lcl/interfaces/win32/win32wscustomlistview.inc
===================================================================
--- lcl/interfaces/win32/win32wscustomlistview.inc	(revision 47221)
+++ lcl/interfaces/win32/win32wscustomlistview.inc	(working copy)
@@ -223,26 +223,6 @@
     WM_NOTIFY:
     begin
       case PNMHdr(LParam)^.code of
-        NM_CLICK, NM_RCLICK:
-        begin
-          // A listview doesn't get a WM_LBUTTONUP, WM_RBUTTONUP message,
-          // because it keeps the message in its own event loop,
-          // see msdn article about "Default List-View Message Processing"
-          // therefore we take this notification and create a
-          // LM_LBUTTONUP, LM_RBUTTONUP message out of it
-          WinProcess := False;
-          if PNMHdr(LParam)^.code = NM_CLICK then
-            Msg := LM_LBUTTONUP
-          else
-            Msg := LM_RBUTTONUP;
-          Pos := GetClientCursorPos(PNMHdr(LParam)^.hwndFrom);
-          // to make correct event sequence in LCL we should postpone this message
-          // since we are here after call of CallDefaultWindowProc
-
-          // TODO: prevent getting more than one Up, Down message by LCL
-          PostMessage(PNMHdr(LParam)^.hwndFrom, Msg, 0, MakeLParam(Pos.x, Pos.y));
-          Result := True;
-        end;
         LVN_GETDISPINFOA, LVN_GETDISPINFOW:
           HandleListViewOwnerData(TCustomListViewAccess(AWinControl));
         NM_CUSTOMDRAW:

Juha Manninen

2014-12-26 23:37

developer   ~0079969

Should both patches be applied?

Michl

2014-12-27 00:40

developer   ~0079970

IMHO the workaround can be removed (patch2). I'm not 100 percent sure whether this workaround with an older version of Windows is required (see comment in to remove code (click on "Show Content" of patch2)).

Juha Manninen

2014-12-27 12:13

developer   ~0079974

Ok, now I understood the idea. They are alternative patches for the same code block.
Can somebody please test if patch number 2 can be used with old Windows versions.
I only have Windows 7 now. The first patch should be safe in any case.

We still support Win98 but it will be dropped together with the coming Unicode FPC.
Now we are interested in Windows 2000, XP etc.

Bart Broersma

2014-12-27 15:55

developer   ~0079980

I'll see if I can test on Win98 (with 1.2.6, cannot find an svn client that runs on win98 anymore).

Juha Manninen

2014-12-27 16:29

developer   ~0079982

Bart, do you have Windows 2000 or XP?
I would guess the workaround is done for Win9x and the patch could be applied when it is not supported any more, maybe in trunk after 1.4 is branched.

Bart Broersma

2014-12-27 16:41

developer   ~0079983

Patch2 breaks ListView on Win98.
I don't have an XP machine to test, nor W2K.
B.t.w. the second mouse-up is only sent if you click outside an item AFAICS?

Michl

2014-12-27 17:28

developer   ~0079986

Last edited: 2014-12-27 17:53

View 5 revisions

> B.t.w. the second mouse-up is only sent if you click outside an item AFAICS?

That is also so on Win7. Patch1 and patch1 can't be applied in that way.

Thank you for your hint!

Edit: OnMouseDown isn't triggered, when mouse is clicked, its triggered on mouse up. There is something more wrong (only on Item not SubItem - there patch2 is ok).

Edit2: OnMouseDown/OnMouseUp works right with patch2 on Item, when you click on a Item and move the mouse a little bit (a new message is send).

BrunoK

2015-01-01 17:51

reporter   ~0080066

Windows XP/32

.\1.3\lcl\interfaces\win32\win32wscustomlistview.inc ln:227 and following.

        NM_CLICK, NM_RCLICK:
        begin
          WinProcess := False;
          Result := True;
        end;
        LVN_GETDISPINFOA, LVN_GETDISPINFOW:
  .
  .
  .
gives me with the left mouse button
  Form1.ListViewOnMouseDown // 1 x
  Form1.ListViewOnClick // 1 x
  Form1.ListViewOnMouseUp // 1 x

and right mouse button
  Form1.ListViewOnMouseDown // 1 x
  Form1.ListViewOnMouseUp // 1 x

seems that XP sends one WM_xButtonUp message event without the need for a supplementary PostMessage.

Juha Manninen

2015-01-28 22:29

developer   ~0080651

I applied patch1, then reverted it and applied patch2.
Patch1 will be merged to 1.4, patch2 remain only in trunk.
It means trunk will not support Win9x any more. There will be Unicode changes that brake it anyway.

Maxim Ganetsky

2015-01-29 01:13

developer   ~0080655

@Juha. OnMouseUp still fires twice on Windows XP with Lazarus 1.4RC1. It works OK with Lazarus 1.5. So I guess this workaround should be disabled for Windows XP and newer OS.

Juha Manninen

2015-01-29 08:39

developer   ~0080662

Maxim, could you change it directly in the fixes branch. This is a special case because trunk uses a different change.
If that is not possible then I must revert the trunk commit temporarily, then we fix XP there and merge, then I reapply the trunk commit.
Assigning to you...

Michl

2015-01-29 10:01

developer   ~0080664

Please revert this patch, it doesn't work correct (as I wrote 5 posts before). Have a look at attached new example ListViewMouseUp2.zip. Click a item on the first Column. When the item got the focus, only OnMouseDown is called - therefore (as Bart sayed) it was the workaround!

When I have time, I will look for a other solution (to the time I'm busy). For now I would only revert the changes r47557, r47558!

Sorry for the circumstances!

Michl

2015-01-29 10:02

developer  

ListViewMouseUp2.zip (3,602 bytes)

Juha Manninen

2015-01-29 12:02

developer   ~0080668

Patch2 works doesn't it? It is now applied in trunk. Patch1 was applied but reverted.
It means trunk is now OK and nothing should be merged to 1.4. Is this correct?

Michl

2015-01-29 13:13

developer   ~0080670

Last edited: 2015-01-29 14:08

View 4 revisions

> Patch2 works doesn't it?

No, it work only for not selectable items!


> It is now applied in trunk. Patch1 was applied but reverted.
It means trunk is now OK and nothing should be merged to 1.4. Is this correct?

No, I've build Laz 47558. On items only OnMouseDown is fired (please test ListViewMouseUp2.zip and click on a item on the left side). Both patches aren't correct until the OnMouseUp for the selectable items is implemented!

Juha Manninen

2015-01-29 14:21

developer   ~0080671

Ok, I reverted them separately and marked one for merging. Sorry for the hassle.

Maxim Ganetsky

2015-01-29 23:41

developer   ~0080676

Last edited: 2015-01-29 23:47

View 2 revisions

Reversion is merged to fixes.

Juha Manninen

2015-12-16 16:51

developer   ~0088012

Checking for the situation. Are the changes still needed? Trunk 1.7 does not support Win9x any more. Makes things easier.

Michl

2015-12-17 00:22

developer   ~0088022

> Checking for the situation. Are the changes still needed? Trunk 1.7 does not
> support Win9x any more. Makes things easier.

Is Windows 32 bit not longer a target for Lazarus or only Windows 9x? Where can I find this information?

Please note I dont use Windows 9x, I use Windows 7 with 32 bit and have this issue (for me it isnt a problem, cause I know it) but that issue is stil here.

There is also a Windows 10 bit available with maybe that behaviour. Do you really stop to support 32 bit Windows?

Juha Manninen

2015-12-17 12:16

developer   ~0088032

> Is Windows 32 bit not longer a target for Lazarus or only Windows 9x? Where can I find this information?

It was in Lazarus mailing list and in forum announcements section.
 http://forum.lazarus.freepascal.org/index.php/topic,30677.0.html

> Do you really stop to support 32 bit Windows?

No. Where did you pull that idea from?

Anyway, can you please create another patch for latest trunk. No need to care about Win98 any more. I would like to finally resolve this issue.

Michl

2016-02-01 14:15

developer   ~0089652

Sorry for that late reply, I'm very busy, but if I have time, I try to do my work ;)

>> Do you really stop to support 32 bit Windows?
>No. Where did you pull that idea from?
I mistake some infos, English is not my best language.

> Anyway, can you please create another patch for latest trunk. No need to care
> about Win98 any more. I would like to finally resolve this issue.
It isn't a issue of Win98! IMHO it is a issue for all Windows ListViews, see https://msdn.microsoft.com/de-de/library/windows/desktop/bb774734%28v=vs.85%29.aspx

If there is a click on a item, the click is handled in the ListView (read on the linked page "WM_LBUTTONDOWN"). If the click isn't on a item, the click isn't handled in the ListView. So you have to check where the click is.

The patch with the best solution I found (tested on different examples) attached.

Michl

2016-02-01 14:20

developer  

win32wscustomlistview16-02-01.inc.patch (2,775 bytes)   
Index: lcl/interfaces/win32/win32wscustomlistview.inc
===================================================================
--- lcl/interfaces/win32/win32wscustomlistview.inc	(revision 51467)
+++ lcl/interfaces/win32/win32wscustomlistview.inc	(working copy)
@@ -215,6 +215,16 @@
     end;
   end;
 
+  function OwnMouseUpNeeded(ALV: TCustomListViewAccess): Boolean;
+  var
+    LVInfo: PWin32WindowInfo;
+    ListItem: TListItem;
+  begin
+    LVInfo:= GetWin32WindowInfo(ALV.Handle);
+    ListItem := ALV.GetItemAt(LVInfo^.MouseX, LVInfo^.MouseY);
+    Result := Assigned(ListItem);
+  end;
+
 var
   Pos: TSmallPoint;
 begin
@@ -224,25 +234,24 @@
     begin
       case PNMHdr(LParam)^.code of
         NM_CLICK, NM_RCLICK:
-        begin
-          // A listview doesn't get a WM_LBUTTONUP, WM_RBUTTONUP message,
-          // because it keeps the message in its own event loop,
-          // see msdn article about "Default List-View Message Processing"
-          // therefore we take this notification and create a
-          // LM_LBUTTONUP, LM_RBUTTONUP message out of it
-          WinProcess := False;
-          if PNMHdr(LParam)^.code = NM_CLICK then
-            Msg := LM_LBUTTONUP
-          else
-            Msg := LM_RBUTTONUP;
-          Pos := GetClientCursorPos(PNMHdr(LParam)^.hwndFrom);
-          // to make correct event sequence in LCL we should postpone this message
-          // since we are here after call of CallDefaultWindowProc
-
-          // TODO: prevent getting more than one Up, Down message by LCL
-          PostMessage(PNMHdr(LParam)^.hwndFrom, Msg, 0, MakeLParam(Pos.x, Pos.y));
-          Result := True;
-        end;
+          if OwnMouseUpNeeded(TCustomListViewAccess(AWinControl)) then
+          begin
+            // A listview doesn't get a WM_LBUTTONUP, WM_RBUTTONUP message,
+            // because it keeps the message in its own event loop,
+            // see msdn article about "Default List-View Message Processing"
+            // therefore we take this notification and create a
+            // LM_LBUTTONUP, LM_RBUTTONUP message out of it
+            WinProcess := False;
+            if PNMHdr(LParam)^.code = NM_CLICK then
+              Msg := LM_LBUTTONUP
+            else
+              Msg := LM_RBUTTONUP;
+            Pos := GetClientCursorPos(PNMHdr(LParam)^.hwndFrom);
+            // to make correct event sequence in LCL we should postpone this message
+            // since we are here after call of CallDefaultWindowProc
+            PostMessage(PNMHdr(LParam)^.hwndFrom, Msg, 0, MakeLParam(Pos.x, Pos.y));
+            Result := True;
+          end;
         LVN_GETDISPINFOA, LVN_GETDISPINFOW:
           HandleListViewOwnerData(TCustomListViewAccess(AWinControl));
         NM_CUSTOMDRAW:

Bart Broersma

2016-02-01 15:50

developer   ~0089654

IIRC previous solutions messed things up in Win98, hence the remark about it being easier now that we need not worry about that.

Michl

2016-02-01 19:23

developer   ~0089659

Last edited: 2016-02-01 19:23

View 2 revisions

I forgot to write, I've tested the patch on Windows7 and Windows10 and it works fine on that systems.

> IIRC previous solutions messed things up in Win98, hence the remark about it
> being easier now that we need not worry about that.
OK, I understand.

Juha Manninen

2016-02-01 22:36

developer   ~0089664

I applied the patch, thanks. I did only minimal testing. Please test more.

Michl

2016-02-01 23:49

developer   ~0089668

Thank you!

I will still leave the report open for a while if someone has a complaint.

Juha Manninen

2016-02-03 16:37

developer   ~0089729

Well, it is not open, it is resolved, but it can be reopened if a problem occurs.

Michl

2016-02-03 17:34

developer   ~0089734

Yes, I know. But can't be opened, when I close it. Thatswhile I don't close it or should I?

Juha Manninen

2016-02-03 18:21

developer   ~0089735

No hurry. It is up to you.

Michl

2016-02-05 08:39

developer   ~0089777

I think, everything is fine.

Martin Friebe

2020-04-19 00:32

manager   ~0122238

@Michl The Listview mouse event handling code has been reworked (again) for more fixes.

Please test again with revision 63012.

See note 0035362:0122233 on issue 0035362

Issue History

Date Modified Username Field Change
2014-12-20 14:01 Michl New Issue
2014-12-20 14:01 Michl File Added: TestListViewMouseUp.zip
2014-12-20 14:01 Michl File Added: patch1_win32wscustomlistview.inc.patch
2014-12-20 14:02 Michl File Added: patch2_win32wscustomlistview.inc.patch
2014-12-20 14:02 Michl Tag Attached: patch
2014-12-26 23:37 Juha Manninen LazTarget => -
2014-12-26 23:37 Juha Manninen Note Added: 0079969
2014-12-26 23:37 Juha Manninen Assigned To => Juha Manninen
2014-12-26 23:37 Juha Manninen Status new => feedback
2014-12-27 00:40 Michl Note Added: 0079970
2014-12-27 00:40 Michl Status feedback => assigned
2014-12-27 12:13 Juha Manninen Note Added: 0079974
2014-12-27 15:55 Bart Broersma Note Added: 0079980
2014-12-27 16:29 Juha Manninen Note Added: 0079982
2014-12-27 16:41 Bart Broersma Note Added: 0079983
2014-12-27 17:28 Michl Note Added: 0079986
2014-12-27 17:32 Michl Note Edited: 0079986 View Revisions
2014-12-27 17:32 Michl Note Edited: 0079986 View Revisions
2014-12-27 17:50 Michl Note Edited: 0079986 View Revisions
2014-12-27 17:53 Michl Note Edited: 0079986 View Revisions
2015-01-01 17:51 BrunoK Note Added: 0080066
2015-01-28 22:29 Juha Manninen Fixed in Revision => r47557, r47558
2015-01-28 22:29 Juha Manninen Note Added: 0080651
2015-01-28 22:29 Juha Manninen Status assigned => resolved
2015-01-28 22:29 Juha Manninen Resolution open => fixed
2015-01-29 01:13 Maxim Ganetsky Note Added: 0080655
2015-01-29 01:13 Maxim Ganetsky Status resolved => assigned
2015-01-29 01:13 Maxim Ganetsky Resolution fixed => reopened
2015-01-29 08:34 Juha Manninen Assigned To Juha Manninen => Maxim Ganetsky
2015-01-29 08:39 Juha Manninen Note Added: 0080662
2015-01-29 10:01 Michl Note Added: 0080664
2015-01-29 10:02 Michl File Added: ListViewMouseUp2.zip
2015-01-29 12:02 Juha Manninen Note Added: 0080668
2015-01-29 13:13 Michl Note Added: 0080670
2015-01-29 13:14 Michl Note Edited: 0080670 View Revisions
2015-01-29 13:15 Michl Note Edited: 0080670 View Revisions
2015-01-29 14:08 Michl Note Edited: 0080670 View Revisions
2015-01-29 14:21 Juha Manninen Note Added: 0080671
2015-01-29 23:41 Maxim Ganetsky Note Added: 0080676
2015-01-29 23:41 Maxim Ganetsky Status assigned => new
2015-01-29 23:42 Maxim Ganetsky Assigned To Maxim Ganetsky =>
2015-01-29 23:47 Maxim Ganetsky Note Edited: 0080676 View Revisions
2015-12-16 16:51 Juha Manninen Note Added: 0088012
2015-12-16 16:51 Juha Manninen Assigned To => Juha Manninen
2015-12-16 16:51 Juha Manninen Status new => feedback
2015-12-17 00:22 Michl Note Added: 0088022
2015-12-17 00:22 Michl Status feedback => assigned
2015-12-17 12:16 Juha Manninen Note Added: 0088032
2016-02-01 14:15 Michl Note Added: 0089652
2016-02-01 14:18 Michl File Added: win32wscustomlistview16-02-01.inc
2016-02-01 14:20 Michl File Added: win32wscustomlistview16-02-01.inc.patch
2016-02-01 15:50 Bart Broersma Note Added: 0089654
2016-02-01 19:23 Michl Note Added: 0089659
2016-02-01 19:23 Michl Note Edited: 0089659 View Revisions
2016-02-01 22:34 Juha Manninen File Deleted: win32wscustomlistview16-02-01.inc
2016-02-01 22:36 Juha Manninen Fixed in Revision r47557, r47558 => r47557, r47558, r51471
2016-02-01 22:36 Juha Manninen Note Added: 0089664
2016-02-01 22:36 Juha Manninen Status assigned => resolved
2016-02-01 22:36 Juha Manninen Resolution reopened => fixed
2016-02-01 23:49 Michl Note Added: 0089668
2016-02-03 16:37 Juha Manninen Note Added: 0089729
2016-02-03 17:34 Michl Note Added: 0089734
2016-02-03 18:21 Juha Manninen Note Added: 0089735
2016-02-05 08:39 Michl Note Added: 0089777
2016-02-05 08:39 Michl Status resolved => closed
2018-03-11 12:18 Michl Relationship added related to 0033330
2018-05-31 20:20 Michl Relationship added related to 0033811
2020-04-19 00:32 Martin Friebe Note Added: 0122238