I have 2 checkboxes. When I click on the 1st I want to disable the 2nd while the 1st one is working. I can make it inactive by set enable = false but it still can be clicked and execute its code when the 1st is done. How can I prevent the inactive checkbox being clicked?
I apologize for the delayed response, I had some urgent work.
I updated to the latest version enabled by my license (v2022R4.1) and the ‘ValueChanged’ event is there but it acts the same way as ‘Action’ event.
Here is a sample project, it needs MBS delay plugin (maybe that’s the problem?)
NOTE: I know delay is not recommended in Xojo but I think it’s needed here.
I send some serial data to an external device and some wait needed between bytes.
Then the device do some stuff for a second, I also need to wait that before another (or the same) checkbox sends any data again.
I’m still not sure I’m seeing the behavior you describe.
My first recommendation would be to implement this in an asynchronous event driven manner to keep the UI responsive while you perform communication with a serial device.
When you do synchronous things on the main thread you lock up the UI, and if you use shortcuts to get around that you risk destabilizing your program.
When checkbox1 pressed Checkbox2 should be inactive for 1 second and do not accept click for that time (change delay to 5 seconds to see the phenomenon better).
And the other checkbox and the segmented button inactive during the delay? During the delay they should be inactive too.
When you click on checkbox2 during the delay it not change but when the delay ends it change its state (same for segmented button)
Win10 (22H2)
Then the device do some stuff for a second, I also need to wait that before another (or the same)
That device do not send an ack (or some sort of done information) ?
The problem is that disable doesn’t take effect until after the button action event ends. By that time, your code has completed and any clicks have just queued up in the event loop. You need to get your long-running code out of the action event via CallLater or a Thread.
This is generally a very good tip.
Don’t write computationally intensive code in events that can impact the user experience. Such code usually belongs better in threads or workers.