Property Node Disabled Constant Reshape

[Guy Drew]

Provide a selectable Name Format for the Disabled Property Node Constant. I understand making the constant an enumerator to provide code documentation. It would be nice to select the Initials by Function to save wiring diagram space (see below).

Do you ever disable controls, I do it all the time and I’m sure you’ve done this.

I created a VI to do just that and save wiring diagram space.

I’ve attached this VI and a Polymorphic VI version of the Disabled Property Node Constant. Use this Polymorphic VI to substitute the property node constant with an initial by function icon. This will reduce block diagram space while still providing limited code documentation. Select between polymorphic instances E) Enabled, D) Disabled and G) Disabled and Grayed Out, by function just as you would the constant.

[A-T-R]

MEGA-KUDOS!

Brilliant!

This bothers me so much...if NI doesn't change it, I will go nuts some day!

Perhaps a right-click option "hide full name" could be provided, similar to the PropertyNodes...

[AristosQueue (NI)]

Personally, I'm in the camp that prefers complete description on the block diagram. I could back changing the name of the enum item to "Grayed out" except for the sheer amount of code that would be broken where people have used the to/from string funcitonality in their VIs. But I like the full name rather than the cryptic single character.

Compromise: You change those poly VIs to have icons on them that some how depict a control as enabled/disabled/grayed and then I might get behind this idea. I'm always in favor of glyphs over text so long as the glyphs are clearly indicative.

[Guy Drew]

If you prefer the full name and the single character was an option, it would have no affect on your code. I believe that a single character (E, D or G) on a disabled property node would only be cryptic for beginners, not for experienced programmers.

[AristosQueue (NI)]

> I believe that a single character (E, D or G) on a disabled property node

> would only be cryptic for beginners, not for experienced programmers.

Problem would be the beginner who has to read the expert's code. 🙂

C# and JAVA have both pushed hard on text programmers to go to complete names instead of mystic abbreviations, and it has massively improved the ability of even experts to read that code. I'd be surprised to find that is different for LV programmers. If E, D, and G are the only examples in the whole language, fine, but it isn't something you can do systemically.

[Darin.K]

My biggest issue is by far wiring an adjective in the enum to a property with an adjective for a name.  A property named 'Disabled' is asking for a Boolean (IMO).  I'd prefer calling it 'State'.  Just sayin.  

Wiring an abbreviation of an adjective into an adjective is only slightly less irritating to me.

[donkdonk]

I recently used a lot of these property nodes and yes they take a lot of diagram space.

However, I agree with Aristos Queue that things should have full names (in other words: be selfdescriptive).

I could live however with a shorter description, for instance "Grayed Out" in stead of "Disabled and Grayed Out", as grayed out already gives you the feeling that it cannot be accessed.

I also agree with Darin.K that it is strange to name a property "Disabled" while it can be wired by an adjective in the enum, named "Disabled".

However his suggestion for calling the property "State" is a bit too general (IMO). Then you could also think of whether the control is "in the blinking state" or "key focussed state" or "data binding led visible state" etc. 

I would suggest: "UserAccess", "Accessibility" or simply "Access".

(On the other hand I can understand that "disabled" was chosen; allthough not formally correct, most people would immediately grasp the idea of this property).  

[thatguy]

I like this.

Use the the context help to show the full description.

[MBohnet]

actually, there is a short form: 0, 1 or 2. Its not that hard to remember...

OK, that sounded rude. Sorry. But: While full text is self-explanatory, E/D/G doesn't say much more than 0/1/2 if someone isn't used to reading Labview code.

If i'd change something about this functionality, i'd remove the 1-case: Controlls that look normal but do not react confuse or even anger the user, so I always gray out if i use this - and after removing "1", a boolean disable flag would be enough...

[JackDunaway]

>> Guy Drew wrote: I created a VI to do just that and save wiring diagram space.

This does not only save diagram space, it reduces code duplication by creating a reusable, recognizable component, so you've really already converged on the best option! By the way, great icon on that SubVI!

>> Aristos Queue wrote: Personally, I'm in the camp that prefers complete description on the block diagram.

Likewise. I'm a huge fan of keeping as much text visible as possible, even at the expense of BD real estate. (see further rationale on Show Names on CLFN)

[Darin.K]

As I paid attention to this while looking at my code I am even more convinced that not only is it more intuitive for a property named Disable to accept a Boolean, it really makes much more sense from a usage standpoint. Add a separate Boolean property to control graying out when disabled (default true and left alone 99% of the time). Like previously mentioned, disabled and not grayed out controls cheese me off. I would suggest a new 'Enabled' property which takes a Boolean. Add the Grayed Out property as well for completeness, and try to get the Disabled property to wither on the vine.