68532 - WebListbox DoublePressed not working
Sorry, I didnât see this post before I posted over there:
I replied to Ricardo, so he can take a look at the time between clicks.
And I replied that I still canât get it to fire anywhere near consistently no matter how fast I try to double click. If double click speed really is the issue then it is set to a super human level that nobody I know would naturally use. That is carpel tunnel syndrome waiting to happen.
It remembers me the time I played Summer Games, we had to press the button pretty fast.
Here is a GIF from your sample:
Try as I might, I cannot get it to do that for me. Perhaps it an age thing, or a Windows thing, but double clicking as fast as I can, the event still fails to fire for me at least half the time.
Have you tried a different browser? Maybe itâs that.
Sorry I canât test using Windows.
Same results in Chrome, Safari and Firefox on this mac 10.14.6, the second click should be fast (not ânaturalâ).
No. Chrome is the corporate browser of choice and double clicking everything else I can find works just fine in that browser. Suggesting it is a browser problem is a cop out.
1 Like
I added a double pressed event to a listbox in my test application. It gives me the same message box as in @AlbertoD GIF. On Windows with either Chrome or Edge, the event is fired every time I tried normally. If however the delay between clicks is too long, then it does not fire.
It is possible to adjust the speed of a double-click faster or slower in mouse parameters. to fit your preferences. I set mine a bit faster the default interval. The screenshot in in French, but it should be easy to understand.
Hope this helps,
1 Like
The default time between clicks of a double click for Microsoft is 500ms, minimal settings are 200ms and max 900ms. Xojo should pursue those numbers, specially that 500ms.
1 Like
Expecting me or any of my users to adjust their double click speed for one control is patently ridiculous. In over 30 years of using a mouse I have never had to adjust the OS settings for double click speed for any application or any platform. This is a problem with the control not the users.
1 Like
This seems to indicate Xojoâs Web doubleclick could be not native. The browser provides double click natively, with no need whatsoever to time it.
It should be possible to implement double click browser side that way, with no inconsistencies due to roundtrip.
5 Likes
Thank you everyone for all the feedback and info, weâll check this ASAP.
2 Likes
Whoa wait. I had a very good reason for asking that is browser based.
The underlying control didnât natively support double clicks back then so i had to write code to accomplish it⊠and itâs tricky to do when the control does natively support single clicks.
Basically, the problem is: when a click occurs, how long do you wait for a second click to occur to say that itâs not a double-click while simultaneously not causing single clicks to feel laggy to the user. Oh, and the browser doesnât allow you to know what the userâs preference on their computer is, so you need to make an educated guess. One user who likes very fast double clicks will probably like any implementation while a user who prefers a longer double click interval will probably have lots of problems because the code just doesnât wait long enough.
Now, while Xojoâs goal is to abstract you from all of the browser differences and recent browsers do make that easier, anyone who writes native web apps and lots of JavaScript code will tell you that there are still behavior differences between then as well as outright bugs that pop up from time to time.
The reason that I asked was to help Xojo get to the root of the problem quickly. If you took your car to a mechanic, described that it makes a funny noise and when they asked you to describe the noise, and you said âsuggesting that the type of sound matters is a cop outâ iâd imagine they might just tell you to go jump off a bridge.
But thatâs just my 2 cents.
NOTE: After having been at Xojo for all those years and now out doing other things, I still want to see the frameworks evolve and grow. That said, we all need to be cognizant that itâs rare that more information is less helpful when trying to track down an issue like this.
4 Likes
Behind every innocent question, there is a good -compatibility horror- story behind. 
Even this double click event is supported on almost every browser⊠except on Android devices, of course.
The most recent example I saw on the framework is the âfocusâ on buttons and Safari. Greg, I saw you had to add specific code to support it.
The more information we have, the better (and the quicker weâll be able to fix the issue).
2 Likes
same here doubleclic works sometimes, itâs a matter of timing.
depending on browser itâs almost impossible to achieve for the end user.
1 Like
My immediate thought is that I would rather know where the workarounds are and have the ability to tell my user that my application relies on functionality that their browser doesnât support and recommend an alternative or let them continue with the knowledge that some things wonât work.
Early on in testing Web2.0 I found that some functions didnât work on the Brave browser and in discussion with @Greg_O_Lone we found that Brave had cut some of the exception raising functionality in their version of Java Script - no way around this so I stopped using Brave as my browser.
I donât have an issue calling out browser manufacturers for shorting us on functionality. Iâm also somewhat in awe of the abstraction the framework provides from these issues.
No doubt you all have your own opinions and Iâd like to see them, but donât want to start a flame war 
2 Likes
Here is more information on what I see:
Computers used: mac mini Mojave, macbook pro Catalina
Using: mouse, trackpad
What I see: Web 2 doublepressed needs to be faster than Web 1/Desktop for it to work. I can get 100% doublepressed working but I need to focus to do it, in normal operations (our web 2 test app) sometimes I forgot about the doublepressed speed and need to do it again (I missed the first time).
Looks like Tomâs problem is worse, I wonder if he is testing with a machine with touchscreen or maybe something else.
1 Like
This morning I tested the same test app I supplied in my feedback case on 3 different computers.
- My normal Windows 10 development laptop using both Chrome and Microsoft Edge
- A second Windows 10 desktop using both Chrome and Microsoft Edge
- My development Mac running Mac OS 12.3.1 Monterey using Chrome and Safari
In all cases tested I could not consistently get a DoublePressed event to fire consistently. The double click speed required to achieve a DoublePressed event has to be uncomfortably fast to register as a DoublePressed event. The only way I could consistently get the event to fire was to triple click so that the acceleration require for a third click caused the event to fire.
This will be an issue for users. They do not and will not adjust their double click speed for a single type of control. Their demand will be for me to âfix itâ. Make it work like the previous version of the app which is Web 1.0.
There in lies the issue. The user has to know about and really focus to achieve a double click speed that will trigger the DoublePressed event. That is unacceptable for every user Iâve spoken to. They want the speed to be as natural as any other control in the app. For some it took 3 or four attempts to get a double click to work which defeats the entire purpose of double clicking a WebListbox row to save a step instead of click to select and the press a button somewhere.
2 Likes