I filed the feedback case

Targets Web
21

On Mac Mini M1 under Monterey, Safari, Firefox and Chrome, I tried the Javascript example at

The doubleclick triggers even for rather lengthy double click, like 1/5 second, as well as much faster.

So it seems the issue is tied to Xojo implementation, rather than the browsers. It seems possible to devise a workaround.

22

What you mean?

image
image1074×220 7.68 KB

1 Like
23

My Android device works with both: Tom’s code (need to do it fast) and w3schools ondblclick examples.
Default Chrome browser.

1 Like
24

From what I can see Web 2.0 is far newer than native browser support for ondblclick so not sure why there’s a workaround/hack rather than using the native behaviour.

1 Like
25

Sorry, it was an example, didn’t get into this one yet. If it’s supported everywhere that’s perfect =)

2 Likes
26

We’ve been reviewing this issue and yes, the value was a bit low. Now that the double click event is supported, the goal is to replace our implementation with browser’s event, so it’s more accesible.

In 2022r2, we’ll be increasing the time between clicks from 200ms to 500ms (it’s 400ms by default on Linux, @Rick_Araujo checked on Windows and is 500ms there). We’ll make sure that this change doesn’t delay other events, like SelectionChanged.

In 2022r3, unless we find any compatibility issue, we’ll replace our implementation with the native browser double click event.

Thank you everyone.

7 Likes
27

Thanks for the update @Ricardo_Cruz. This sounds like the best solution.

1 Like
28

The double click is a complement to the first click. SelectionChanged should be rised from the first one no matter if there is going to be a DoubleClick.

There is another problem that you are not considering. The TIME is only one HALF of what is considered to make a double-click. It is the maximum number of milliseconds that can elapse between a first click and a second click to consider the mouse action a double-click. 500ms is a good default.

People are used to the standar way in which something works, if you make a half baked implementation of that behavior, many are going to complain about strange behavior.

To have a better “hand made” double click implementation, you must implement the DoubleClick SIZE. The DEFAULT on windows for this is a region of 4px by 4px, if the second click is outside this region, it must be a second click NOT a double click

1 Like
29

As far as I can tell (from testing here), that is handled by the ondblclick event.

1 Like
30

Try 400 to 450 first. I even saw people enforcing 450 (subtracting -50ms when finding 500+ in some apps). And later check the necessary cascade of dependent events and enforce it. Like, only examines and fires SelectionChanged after the examination of DoubleClick, if one could be possible in such context. Doubleclick->click(if not double)->selection(if a click) This will allow you select a group of records and execute a double click on them.

1 Like
31

ondblclick sure, it is goingto be there IF xojo uses it. But Im talking about the Hand Made detection xojo has now.

32

Correct, now is too fast and until ondblclick is part of Xojo, we need to test the beta when available to make sure the time is not too long and users can’t double click if the mouse moved more than a few pixels. Thanks for the heads-up.

33

In 2022r2 you will receive a SelectionChanged whenever the selection has changed, no matter if it’s a single click or double.

We are not measuring the distance between the clicks, but the row where you’ve been pressing:

  • If you’re just doing a single click, it will be sent to the server after the grace period.
  • If you press twice in the same row, you’ll get the DoublePressed event.
  • It’s challenging, but if you manage to press on one row and then press really quick on another row, you will receive a single Pressed event on each.

I would love to hear what you all think, as soon as the testing phase begins.

4 Likes
34

And I assume a click selection also occurs with a right click which was part of the contextual menu fix?

35

Yes, right clicking on a row will display the Contextual Menu, if present, and make sure the row will get selected. If it wasn’t selected, then you will also receive the SelectionChanged event.

3 Likes
36

I’m not sure that ondblclick is new; compatibility is listed back to IE4, Firefox 9, Safari 1 and Chrome 1.

What’s great news is that Xojo will look to use the default behaviour.

37

I believe Ricardo means supported/implemented by Xojo. But I’m not @Ricardo_Cruz so I’m just asuming

1 Like
38

It’s not just the event, the underlying component has event handlers also that can be in conflict. I’m sure back then it was necessary to implement it that way.

The same happens with other components or layers of the framework.

Hopefully we’ll be able to replace it on 2022r3 anyway, and keep improving it :blush:

1 Like
39

The advantage of ondblclick is that it is client side. So it should work no matter the amount of lag.

40

It was always implemented client-side, event with Xojo’s own implementation.

1 Like