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?
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.
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?
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.
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
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.
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
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.
