I have a WebCheckBox that I have subclassed to include a property DisableAction As Boolean. I want to be able to prevent a mouse click from firing the action to change the checkbox value unless the property DisableAction is set to true. I do not want the checkbox itself to be disabled because it will be made transparent and because I am using a contextual menu to select “Edit” to set the DisableAction property to false and change the text color style of the checkbox to indicate the value is now changeable from its original setting.
What is the best way to prevent the value changing so long as DisableAction is True?
Without providing some way for your user to know you’re going to be ignoring their attempts to change the value of the checkbox, you’ll drive them mad with clicking.
If you’re going to tell the user they can’t change a checkbox, disable it. The visual cue lets them know you’re not allowing changes, and the browser will handle not allowing them to change it.
That being said, the code below will do what you ask without waiting for the round trip. Plus, if you handle the return in Xojo, you’d have to set the checkbox back to it’s previous state (more confusion for the user).
I tested this, and it works on the checkbox. Xojo does something that allows the user to click on the label associated with the checkbox so that it behaves similar to desktop checkboxes. I’ve provided the example for how to disable the functionality; I’ll leave you to explore, expand, and figure out how to disable clicking the label.
Update: You will also have to check if you’re ignoring the change with DisableAction in the ValueChanged event as it looks like that gets triggered even when the checkbox is not to do anything onclick.
Thanks Tim. I’ll give that a try. As far as visual queues to the user, ALL text fields, Listboxes and checkboxes in this app must be enabled for editing via a contextual menu selection. This is an internal app that uses a web service to populate all the controls and if a user wants to change a value they have to be very intentional about it. I agree that normally I would disable the control but that means only checkboxes would have that appearance since all text fields are set to read only and Listboxes require a popup dialog to edit a specific field.
Dave and Louis, Yeah I would use return True on a desktop app but that return type is not defined for a mouse down even on WebCheckBox which is why I posed this question.
This is AWESOME Tim! I know I’m not the only one that will be using this . Thanks so much!
Here, let me pique your interest again…
Can I assume that the same approach will work with a Radio Button subclass, (since I haven’t tied it yet)? I suppose this JavaScipt code needs to point to the radio button control type or will “_box” work for a Radio Button too?
The _box came from looking at the source for a checkbox on the page. Turns out, Checkbox is encased in a table to hold the label in place. Maybe it was implemented before the current standards, but it turns out the actual checkbox is ControlID_box and the label is ControlID_caption.
And because I know they would like me to point it out: This subclass uses undocumented stuff from the framework, do not file bug reports if future updates to Xojo break this subclass.