Does it bother you that you have to use values of 0, 1, or 2 to set the disabled state of a control/indicator? It never really bothered me, I guess because I just got used to it. But lots of people think that it should be an enum instead. Well, I don't know how it didn't make it into the Upgrade Notes, but have you seen the Disabled Property in LabVIEW 2009?
So now you don't have to do a number-to-state translation in your head whenever looking at the Disabled property. Of course, you're also losing a lot of diagram real estate. I'll let you decide if it's worth it or not. As for existing code, your old U8 constants will stick around, and you'll see a coercion dot on the property:
I wouldn't worry about the coercions, they're not hurting anything. I don't plan on going through all my existing apps to change them over, although I will probably start using the enum in new apps.
<severely off-topic, unless you know where Broken Arrow's image came from>
You know, I tried watching a Ren and Stimpy episode the other night...just didn't make me laugh like it did in college. Same thing happened when I watched Spaceballs as an adult.
I still never remember the numbers (or I'm always unsure if they are correct). So every time I need to check the help to see that 0 is enabled.
I will like that feature once I get an upgrade.
I'm wondering why not use shorter names for the enum. Like enbld, disbld, disbld gyd or something that makes more sense... Guess it'll serve the purpose of clarity and real estate... The point is, I hate such big enums... ... In fact I dislike the File Handling enums too! They take so much of space...
See the comments in this idea. You may wish to add your own in there as well.
I always wondered why the enum was not here in the first place, I cant think of a large scale application that I didnt use this property. Now that it is here it does raise an interesting issue with graphical programming, real estate is a premium (this was not effercted by the recent real estate bubble). If this was a text based language, using a #typdef is a nobrainer, the code is much more readable and maintainable with little to no disadvantage. That said I will probably use the enum over the U8. I keep most of my GUI architectures in a queued state machine and much of my properties are set in a seperate state (where there is plenty of real estate) so I dont have to stuff a property node in too often.
Once upon a time it was policy of NI to remove as much enums from the IDE as possible, since they all need to be localized for every IDE language, something that was basically not possible, so I wonder how this looks in the french or german version of LabVIEW.