Disabled Property datatype is now enum? (2009)

[Broken_Arrow]

What can I do about the coercions that will occur when I open older stuff? On my current project there are dozens of coercions that I'll either have to ignore or manually change. (?). Am I missing a setting somewhere?

[Darren]

I'm planning on ignoring them in all my existing apps.  The coercions don't hurt anything.

[Broken_Arrow]

---

Darren wrote:

 The coercions don't hurt anything.

---

The above quote shall be plotted to D-size paper and suspended from the water sprinklers.

Thanks Darren. So, it DID change from 861 to 2009, but I don't see it in the release notes.

[Darren]

Hmm, I too was unable to find this in the Upgrade Notes.  I'll make it next week's nugget so it's "official".  🙂

[elset191]

---

Darren wrote:

Hmm, I too was unable to find this in the Upgrade Notes.  I'll make it next week's nugget so it's "official".  🙂

---

Aw, come on.  Now I have nothing to look forward to Monday morning.

[tst]

You could write a VI which will parse the diagram for property nodes, see if they have a disabled property and if that property has a numeric constant wired to it, replace it with an enum of the same value. Of course, this won't handle things like constants in cases or select primitives, which is a reasonably common use case for me. I would agree with the ignoring method.

[JÞB]

---

tst wrote:
You could write a VI which will parse the diagram for property nodes, see if they have a disabled property and if that property has a numeric constant wired to it, replace it with an enum of the same value. Of course, this won't handle things like constants in cases or select primitives, which is a reasonably common use case for me. I would agree with the ignoring method.

---

Or, just use the search in the heirarchy view!!!    It may be time consuming but,  I'd like to look at coersions of this type before I ignored them.  (just cautious I guess)

[Lowell]

Actually, it is worse than a simple type change.  The semantics changed as well.  This WILL break code.

In 8.5 (the latest help page from before 2009 that I looked at) the meaning of the constants are:  0-Enabled, 1-Disabled, 2-Disabled and Grayed Out.  But in 2009, they changed to: 0-Disabled--The object appears as normal on the front panel, but the user cannot operate the object.  1-Disabled and Grayed Out—The object appears dimmed on the front panel, and the user cannot operate the object.  2-Enabled—The user can operate the object.

So, to go from 8.5 to 2009, 0 => 2, 1 => 0, 2 => 1.   If you did "good code", ALL THE TIME, by turning on the label for your constants and labeling them by their meaning, then you can look at the constants and replace them with the correct current enum.  If not, you need to write down the list and check it from against each constant.

Ouch!

[RavensFan]

No, it won't break code.

It is an error in the documentation for LabVIEW 2009 but has been fixed in LV2009 SP1.

See here.

[Lowell]

Thanks!