I am having an issue where if i have a component which has onMouseDown/onMouseUp event scripts to write to a property, if the button (or other component) is clicked/pressed in quick succession, the property reflecting it's state will often not reflect the actual state of the button (button gets "stuck on"). At first i thought this was a touch screen issue but after a day of going down that road i realized that i could replicate the same behavior with a mouse on my desktop. It seems that 5 quick clicks works the best to reproduce this. It will do this in firefox as well as the designer (have not tried any other browsers or workstation).
onMouseDown i'm writing propX True
onMouseUp i'm writing proxX False
You tagged this as Perspective.
Yes, mouse events are unreliable. The mouse event is in the browser, but the event script has to run in the gateway.
This is why Perspective has no momentary pushbutton. The events needed to make such a thing reliable cannot be made reliable. 
(If that is what you are trying to do, switch to Vision for this application, but also search this forum for the things you have to do even there to make momentary buttons reliable.)
1 Like
I couldn't leave this one alone. I dug a bit in an attempt to understand where the weak link is and here is what I found in my particular case.
Using wireshark and an hour of time working on the right filter parameters that would only show when a button was pressed/released I found that some events were not being passed to ignition. Then using js in the browser console i logged mouseup/mousedown events. What i found here is that the browser was reliably seeing the events, but not passing it to ignition every time.
I then created a simple browser extension that would keep track of the mouse/touch state. Every 200ms it will send this state to ignition (via a webdev endpoint) which triggers a script that will update a "mouseState" tag. A gateway timer script also runs that monitors the value of mouseState tag, and if it is False, any tag that is used for momentary actions is set False. The timer script also accounts for missing coms from the browser extension, if more than X coms missed, it will write all "momentary" tags False. I've been testing this for 11 days now and have had 0 "runaway" issues. I would by no means consider this a "fix" but I've learned a few things along the way and it appears that it has at least bought me some time to do something proper.
2 Likes