Mouse events in Web Apps 2020r1

A web app that I have deployed relies on a difference in time (using ticks) between mouse down and mouse up events to determine a behavior. It is an unsophisticated piece of educational software, simulating an experiment, so my students can generate unique data sets for analysis in a physical sciences gened class. I use the time delay to include the effect of experimental error on their data set; longer click = larger force on object; force affects data returned to students.

I developed in previous version (2019r?), works fine. I just allowed xojo to update to 2020r1, and the event handlers I used (mousedown and mouseup) are no longer available for a WebRectangle control, and simulation will no longer work. In fact, I can not find a control object that allows me to implement code under a mousedown or mouseup event handler. Can someone please direct me to where I can now capture and use separate halves of a click?

1 Like

Did you miss the blog posts?
Older posts in this forum?

If you need MouseDown events, please keep Xojo 2019 and wait for 2020r2.

I’m not sure where this idea came from, but we (Xojo) have made no commitment to bringing mouse events back in 2020r2.

Well, I had the impression.
From the Xojo blog:

If your app depends on mouse events for these controls, wait for a future release.

So I assumed this would be 2020r2. But well, it could be later.

1 Like

I didn’t think to look in a blog for language documentation - just read the language reference thoroughly and did a keyword search through the forum and didn’t find what I needed. Thank you for pointing me to the blog; not the way I expected to find documentation of language features, but maybe I’m just old.

Sadly, I also opened my project in xojo 2020r1, and now it won’t open in 2019r32. My fault for expecting compatibility. Time to rebuild from scratch. :confused:

To xojo developers: Will there be access to mouse events in Web2.0 framework? I found the line that Christian mentions in the blog post indicating “later version.” When should we expect that functionality?

1 Like

no backup?

Older than I thought it was. Totally my fault; I should keep better backups. Again - thank you for your help. I’ll be able to continue developing these kinds of educational simulations in an older version of xojo.

I dont think there’s any commitment whatsoever to EVER bring them back because of the latency & traffic they cause

I could be wrong but given conversations in testers when folks noticed this I dont think I’m wrong

1 Like

You don’t need to do it for all instances. Just for those with code in the event handler.


Primarily this would be mouse events for Label, Canvas, MapViewer and ImageViewer. If your app depends on mouse events for these controls, wait for a future release.

However thats still may not include mouse up down etc

@Greg_O_Lone - care to comment ?

Mouse and keyboard events should really be handled client-side. That was a failing of Web 1.0 and 2.0 attempts to improve that. I think the WebSDK allows you to push logic to the browser more easily. It does require some knowledge of JavaScript, but it’s worth it.

1 Like

In the interest of furthering discussion, I’ll offer the link to the deployed app I mentioned. It might help as an illustration of when knowing mouse properties is useful. For context, this is for a class called Science of Craft; we’re using Blacksmithing as a context for learning science principles. I want students to generate a data set that includes human variability (thus click duration and position, instead of simply a ‘pressed’ event) to introduce error. They collect, graph, interpret, etc.
The experiment this simulates is one where we test the temperature dependence of a piece of steel. I do the actual demonstration using a forge in the classroom, then ask the students to generate their own data set with the simulation. To use, press button to insert in forge, watch it heat up, pull it out, then click on the square box to make a dent (it is a webrectangle object). Bigger dents -> softer metal, as long as you are very consistent in your click duration. But also longer click -> bigger dent; off center click -> unequal dent dimensions.
I would be interested in any advice on how to produce this behavior or functionality without the mouse events. Please be kind when critiquing simulation design; I’m rushing through these in response to having to teach this class remotely.

You do realize that there will be wild fluctuations of timing due to latency issues, which is exactly why you should be doing this client-side. You should implement mouse down/up and timing in the browser and then trigger a server-side event that passes the duration as a single value.


IF you assume that all web apps are deployed on the internet then latency etc may be a serious issue. And then Xojo’s choice to not support them makes a certain degree of sense.

But thats not always the case and they may be deployed on a totally private internal network and latency and high volumes of traffic may be a non issue.

In that scenario not having the OPTION to even use mouse & keyboard events could be a crippling shortcoming

Just saying that how you assume they will be used drives certain decisions that may NOT always be accurate


He invited us to use the app over the internet. He also mentioned teaching the class remotely. Thus, latency will be an issue.

Saying “but this one is” doesnt negate what I said
That this one is doesnt mean they all will be
Thats all I said

In this case latency would probably be an issue
But since he has no way to do anything with/for/to/about the mouse events without delving into javascript he’s kind of SOL with Web 2.0



You are correct in the assumption that we are trying to reduce the amount of traffic as much as we can. We have plans for client side text masking and validation as well as a mechanism for chaining together a series of actions to avoid round trips to the server, all in the interest of not having a constant steam of data going to the server and back to the client. With one user debugging locally that may work fine, but in production with 30 or 300? Not so much.

In this case, for an app that needs to record the amount of time a button is pressed, you ought to consider using the WebSDK or pay one of the gurus do it for you. You’ll get much more consistent results that way.

Short cut keys (keyPressed) are also gone . . . Any anticipated return?

Or have we just dumbed everything down to an iPhone level?

1 Like

Can you be more specific about what you are trying to do with “short cut keys”?

Clients use shortcut keys to select and move text from one webListbox to another . . . quickly:.