[revisited] triple click

[dbannon]

I'd like to detect a triple click in a control that does not support it. Seems easy enough to detect a double click, and if a third click happens in, say, 500mS, it must be a triple. I'll be overwriting anything the double click did so, seems safe :

Code: Pascal  [Select][+][-]

1. const CountSinceDouble : qword = 0;
2.  
3. procedure TForm.KMemo1MouseDown(Sender : TObject;  Button : TMouseButton; Shift : TShiftState; X, Y : Integer);
4. begin
5.     if ssDouble in Shift then
6.         CountSinceDouble := gettickcount64()
7.     else if (gettickcount64() - CountSinceDouble) < 500  then
8.         showmessage('triple click');
9. end;

   

I don't want to delve too deeply into KMemo, the control in question, it's several layers down from TControl so restoring its ssTriple is too much trouble. Anyone know a better way or see an inherent flaw in what I have done ?

Thanks,

Davo

[Martin_fr]

Not sure, but should multi clicks occur in the approx same location? => If the 3rd click appears some other place... E.g. another line or paragraph...

Or if there was a click to another control inbetween... (ok, needs a very fast user)

[dbannon]

Hmm, I cannot both move and triple click. But I'm using a touchpad.  Might need to do some experiments with a real mouse. 

Good point Martin.

In the event of movement, I would have only the coordinates of the third click available. But I'd think that would probably the correct ones to select anyway, wouldn't you ?

Will report back ...

Davo

[Tony Stone]

Does your touchpad have a real right and left button?  My Dell Laptop has them but they are annoying to press.  Usually I do clicks by tapping or double tapping anywhere on the touchpad.  But when I need to do a real triple click I almost always have to use the physical touch pad buttons.  Like in my browser to type in a new URL I use the button to triple click and select all of the text in the address bar.  So just letting you know in other applications on another popular Laptop with a touchpad "triple taps" don't really work as they should.

Hmm, I cannot both move and triple click. But I'm using a touchpad.  Might need to do some experiments with a real mouse. 

Good point Martin.

In the event of movement, I would have only the coordinates of the third click available. But I'd think that would probably the correct ones to select anyway, wouldn't you ?

Will report back ...

Davo

[jamie]

That should built from a tcontrol which does have a triple click message u should be able to capture if u subclass the control locally there intercepting the window procedure.

[Zoran]

You can easily access TControl.OnTripleClick using the "protected hack" technique.
Take a look at the attached project (I don't have TKMemo, so in my example I used TStringGrid, which also does not have OnTripleClick event).

[dbannon]

Nice one Zoran, very nice !

I just tried it with KMemo and it works flawlessly. Thanks very much.

Davo

[dbannon]

OK, following on from Jan 2025 !

Back then Zoran showed me a really cool trick to access properties that have become protected as new classes "evolved".  However, I have just discovered this trick triggers off alarm bells if the debugger option Verify Method Calls (-CR) is enabled. And, maybe getting around protected is naughty ?

How naughty ?

[cdbc]

Hi Davo
It can get naughtier... use an interface  it doesn't care about scope, it just has to be implemented -- everything in an interface is public
Just how /allowed/ such trickery is, in the eye of the public -- I dunno 
Regards Benny

[Thaddy]

Code: Pascal  [Select][+][-]

1. type
2.    TAuxStringGrid = class(TStringGrid)
3.    published
4.      property OnTripleClick;  // <----- promote it;
5.    end;
6.  

That may solve the debugger issue.

[cdbc]

Hi
Yup, what Thaddy showed, should work too.
Regards Benny

[Thaddy]

Completed and tested.

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, Grids;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     StringGrid1: TStringGrid;
16.     procedure FormCreate(Sender: TObject);
17.     procedure StringTripleClick(Sender: TObject);
18.   private
19.  
20.   public
21.  
22.   end;
23.  
24. var
25.   Form1: TForm1;
26.  
27. implementation
28.  
29. type
30.    TAuxStringGrid = class(TStringGrid)
31.    published
32.      property OnTripleClick;
33.    end;
34.  
35. {$R *.lfm}
36.  
37. { TForm1 }
38.  
39. procedure TForm1.FormCreate(Sender: TObject);
40. begin
41.   stringgrid1.controlstyle := stringgrid1.controlstyle + [csTripleClicks];
42.   TAuxStringGrid(StringGrid1).OnTripleClick := @StringTripleClick;
43. end;
44.  
45. procedure TForm1.StringTripleClick(Sender: TObject);
46. begin
47.    Showmessage('triple');
48. end;
49.  
50. end.

Debugger does not complain...
This works for Windows. [edit] and Linux Trixie64 + Qt6

I guess the original would have done the same.
Very clean.
         

[dbannon]

Thanks Thaddy, Benny.

Its late here so, will try tomorrow, time permitting.

Grateful for the response !

Davo

[dbannon]

Well, no, that did not work for me. Thaddy did you have "Verify Method Calls" turned on ?

I find, with both gtk2 and Qt5, Lazarus 4.4, FPC 3.2.4rc1 that it still compiles well bt crashes at run time.  Attached is a project, your code, my debug settings. Please test and see if you get same result.

Davo

[Thaddy]

I can't make it crash without -CR but indeed, when it is checked the code will not compile properly.
Since the method is legal (mapped to same space even with the hack), there seems to be a bug in verify method call that also affects code generation.
- The code  without -CR does not crash and sees the correct overlay.
- The code with -CR draws a wrong conclusion and removes code, which causes the crash.

I think -CR contains a bug. Will investigate further on what code is actually generated.

TAuxStringGrid is a TStringGrid. No code is added, no fields are added, only a visibility specifier is promoted. That is legal for -CR.

BTW: It should not crash with the original code anyway: the method is within the visibility of the class, so the "hack"/overlay is not even necessary: again, that points to a bug in the compiler for -CR

[edit]
The Control style change does not affect the code path, so the method call is always correct. It seems -CR uses some kind of hashing that goes wrong.
Changing a field will change a hash, but then that hash is wrong since the method call is not affected. The code path suggests that if the control style is missing, the call does nothing.