Is is possible to have enumerations automatically update their entries?

[ichan]

I am using a subVI which accepts one of a list of several options encoded in a enumeration.  However, whenever I have to add a new option to the subVI, I am forced to manually update the enum selector for every occurence of the subVI.  Is there anyway around this?  Ideally, I would like something along the lines of all these selectors following a common template (like a class in OOP).

[tbd]

Hi ichan,
> I am forced to manually update the enum selector for every occurence of the subVI
It sounds like this control should be based on a typedef - that way, no matter how many places it's used, the enum only needs to be updated in one place.

Try selecting your enum-control on one of the Front-panels and - while it's selected - choose "Customize Control" from the "Edit" menu.  A new "Control" window will pop-up.  At this point I immediately change "Control" to "Type Def." and save-as (new file name) so I don't forget to make it a Type-def.  Replace all the existing Front-panel occurances with the new .ctl (right-click/replace/Select a control...)

Hope it helps!

[ichan]

Hello tbd,

Thanks for your prompt response.  While it certainly taught me something useful that I didn't know before, it wasn't quite what I was looking for; it's my fault for a slight mistake in the way I phrased the question.

Let me try again: so actually, I was hoping to do this for an enumeration _constant_.  To make the situation more clear, I'm making something similar to a functional global variable (the world [aka. NI forums] is giving me strong hints that regular local/global variables are wicked little gremlins that should be avoided as much as possible).  A enumeration constant is used to select which mode the SubVi is operating in, eg. "read", "write", "purge", "intialize" etc.

Now and then I think of a nifty new mode I would like to add in.  While its okay for me to right click on each subVi icon terminal and go "create constant" right now, I'm thinking it'll cause an aneurysm for whoever inherits the code when it get bigger.

I hope this has made it more clear.  Thanks again.

[tbd]

Hi ichan,
      Diagram-constants derived from a Typedef will update with the typedef!  The only thing to be careful of is that any Case-structures you wire the constant to should have Default case - that way, when the new enumeration-value appears, the code won't break. ;^)

Cheers.

Message Edited by tbd on 12-17-2006 01:35 AM

[tst]

---

@tbd wrote:
The only thing to be careful of is that any Case-structures you wire the constant to should have Default case - that way, when the new enumeration-value appears, the code won't break. ;^)

---

Actually, more often than not I find that you do NOT want to have a default case when dealing with enums, so that your code WILL break when you add new values. That way you can be sure that you find all places in your code where you operate on that enum and know that you handled them.

[Ben]

I have to agree with tst re:not using defaults with enums.

I'd rather see the error at edit time than at run time.

Ben

[Ben]

Adding to my previous...

I do occationally use default cases with enums after all.

These are case structures where i want to catch programing errors at run time.

Example:

I develop libraries that can be re-used by the other engineers. Since I don't want my code behaving badly when miss-used, I will enunciate when a bad enum value has been passed.

But in both cases, I want to know as early as possible when an enums value is out of control.

Ben

[tbd]

Hi Folks,
At first I couldn't think of a good exception to tst's and Ben's position - until I re-read the original post...

Ichan wants to "add a new option" to  the enum without breaking existing code; specifying a Default-case allows existing/working source-code to re-compile with augmented enum-typedef.  This would not create a hole for errors to slip-through.

If ichan removes an enumerated "option", that's another situation.  As you probably know (but this is for ichan's sake) when an enumerated-value is deleted in the typedef, diagram-constants refering to the deleted enumeration don't break, they change to another value from the new typedef (at least, in LV7.1 they do.)  After removing an enumerated "option":
   1)  If there's no case for a new/unintended constant-enum-value, catch it in the Default case and raise an error per Ben's instruction.
   2)  If there IS a case for the new/unintended value, well, that potential problem isn't worsened by having a Default case.

Like text-based language compilers, it would be nice if LabVIEW raised a compile-error (broken-errow) when an enum-constant-value, used in the source/diagram, ceases to exist in a typedef.
Cheers!

[tst]

Actually, the way I understand it, the demand in this case was not to have working code not break (since the actual code is only found once - in the subVI), but not having to update every instance of the enum in the calling diagrams. Your explanation that typedefs affect the diagram constants as well answers that question perfectly.

---

...when an enumerated-value is deleted in the typedef, diagram-constants refering to the deleted enumeration don't break, they change to another value from the new typedef (at least, in LV7.1 they do.) 

---

That's why I try to avoid removing items from typedef enums\clusters unless absolutely necessary and\or (I wonder what an And\Or node would look like in LV? ) I'm willing to spend the time and effort to make sure that all the places where the change would take effect have not been altered.

[tst]

---

@tst wrote:

I wonder what an And\Or node would look like in LV?

---

Probably like this.