Despite many years of professional programming for several platforms, every six months or so I get tripped up by the simple fact that checkbox.action also fires when the value has been programmatically changed. Arrrrrrgh!
Now, you’d think I’d just set breakpoints around the checkbox values being changed and step through the code, thus instantly seeing my fallacy, right? Wrong! I step through my code, sure, but I’m always assuming the problem is elsewhere, not with the simple checkbox. A good workman never blames his tools but checkbox.action, I curse you for wasting two hours of my day.
I’m off to watch True Detective to take a break from Biannual Checkbox.Action Day.
I tend to disable the checkbox when I’m setting it programmatically. Then in the Action event I have a simple check for if me.disabled = false then return. Works simple enough.
I subclass such controls and use an integer to track enabled/disabled. That way I don’t have to worry about another event or method prematurely enabling the control.
Nice one. I’ve never thought about doing this. I will use this on my preferences window because at the moment I read in my prefs, set my controls which inevitably writes the preferences back to the file as i’m programatically setting the control values. Not a massive problem but unnecessary. Thanks Bob
Yeah, it’s time I did this. Every time this is problem arises, it’s normally near the end of a project and my default thought process is “well, that HAS to be the last time I’ll make that mistake!”. And then, six months later… But this time, things will be different…!
I did that on a couple of projects. I generally have a load method that loads data into the controls and in that method I simply disable all of the controls and in their respective action/change events do a simple check for enabled. If disabled I return right away.
This is a very simple way to do it since there’s already a property you can use (enabled). That way I don’t have do subclasses (any more than I already do).
Some of this depends on how I’m saving the data. Do I want it in the action/change event or do I have a Save method that does the same thing? Each way has some good points to it.
It might, but it usually happens so fast that none of my clients have ever complained about it. Usually the load happens when the form/window/dialog is opened so there’s no perceived flicker.
On desktop apps the data load can be in the constructor of the window/form/dialog so it happens before the control is shown (or at roughly the same time). Web apps can’t do this, but because there is some caching going on between the server and the browser it’s never seen by the end user. Technically if you are loading a lot of controls (think hundreds) there might be something shown but most UI isn’t that busy.
I used subclassed controls for everything anyway, so adding an extra property and method hasn’t been an issue. But I like the enabled/disabled approach. Very clever.
But