You should not rely on MouseDown/MouseUp events for a checkbox, because the user can change the state of the checkbox via the keyboard. When the checkbox has focus and the user presses SPACE, the ACTION event will fire, but no mouse events.
Using a flag as others have suggested is the best way to handle this.
What we do is have a method on the window that updates the controls, and a property on the window called ‘isUpdating’.
At the start of the method we set ‘isUpdating’ to true, update the interface and then set it back to false at the end.
Then when a control is changed, it checks the state of the ‘isUpdating’ Boolean.
if not isUpdating then
// do thing
End if
There’s probably a better way; but this is how we’ve done it for years.
The input in this thread obviously very valuable to me. As one would guess, there are several ways to accomplish the goal. Ultimately I ended up with the technique outlined by Rowlands because that was best suited to the problem that I had.
In my application, there are many checkboxes and radio buttons that are linked with each other. Their initial state needed to be set at the time of starting the app using data read off of a file that remembered the state from the last session. Then every time a checkbox was clicked, the situation needed to be “re-evaluated” as other checkboxes might need their “state” changed. I could write one routine that would look at the state of all the checkboxes and make necessary adjustments. That window method would set a window property to shut off all the checkboxes so their action events would not run during these adjustments. This was implemented, as Rowlands outlined, by wrapping the action events of all the checkboxes in an if statement accessing the window property to establish whether the updating routine was responsible for triggering the checkbox action event rather than a user action.
There are other circumstances that I could imagine where other suggestions made here would have been more elegant. Keeping everything at the level of the checkboxes themselves with a subclasses checkbox or using the MouseDown/MouseUp action events (and somehow preventing the problem of the keyboard initiation of checkbox activation).
Bujardet stuck with the thread to the end despite some frustration with my persistent confusion. Parnell and Wheel pointed out complications with techniques that had tempted me. Tulin suggested a technique that could have been made to work in a way similar to Rowland. Sampire’s technique would be one that I would prefer under some situations that might arise in the future.
And it was made clear to me that there was no “simple” way to make a checkbox respond only to a user mouse click by subclassing a checkbox. So that by implementing the Rowland technique, I was not doing something “stupid”.
Thanks to all. I have been “away from Xojo” for many years using other tools. I am now struggling to relearn the language and its customs. The existence and the friendliness of this forum make it an invaluable resource. Hope to run into some of you in October in Texas.
[quote=263270:@Robert Livingston]And it was made clear to me that there was no “simple” way to make a checkbox respond only to a user mouse click by subclassing a checkbox. So that by implementing the Rowland technique, I was not doing something “stupid”.
[/quote]
As long as you find a suitable and reliable solution, that is what counts. However, along the discussion there was that “little” detail that can be of importance :
Christian Wheel is quite right : under Windows as default and under Mac OS X when Full Keyboard Access is activated, the user can change the state of a checkbox not only with the mouse, but also with the keyboard. Luckily, Sam Rowlands method works with that as well.