Make every created Enumerated type a Typedef

[Intaris]

We've been saying it for years now.  Enums should be typedefs.

Why not make EACH and EVERY dropped Enum into a typedef automatically.  Drop a new Enum from a palette, it is a typedef.  Copy it, it's linked to the original.  For my taste, even ask for a save path after dropping the enum but for the sake of our sanity, just make each and every enum a typedef already.

[X.]

You could create an empty enum, make it a typedef, save it as a control template and use "New..." and select that template to create a new typedef enum.

Never mind, that's way longer than right-clicking "Make Type Def" and then "Open Type Def"...

which is pretty quick when you think about it (and can be done directly from a constant, terminal or control).

[Intaris]

My idea does not stem from wanting to save time but to simply ENSURE that all enums are typedefs. Different focus altogether.

[Mythilt]

My one problem with this is that it results in loads of enum typedef files that are only used in one subVI.  I wouldn't mind it if there were a way to make the enum typedef part of the VI itself, so it is not a seperate file, but this is not likely to ever happen.

[donkdonk]

I agree with Mythilt: it results in (loads of) enum typedef files.

It's already quite difficult to know/control all the locations of your vi's. At times, it can be very confusing. Adding mandatory typedef files complicates things further.

We have lot's of subvi's at a central location and copy a subset of them to our project folder when needed. Typedef files complicate this. You'll have to know which typedef files to (also) copy.

Sometimes typedefs are used across several vi's, so making them part of a vi (as Mythilt suggests) seems not the way to go.

[Intaris]

I also agree with Mythilt.  It creates lots of files. I think we can probably all agree on that.

Where I disagree is that this inconvenience should get in the way of implementing something properly.

The headaches solved by making each enum a typedef far outweighs the "cost" of a few files.

[JKSH]

@Mythilt, @donkdonk : I'm genuinely curious -- What's the use case for having many once-off enums in a project?

[donkdonk]

@JKSH,

>What's the use case for having many once-off enums in a project?

None.

Our projects are pretty small. Often there's only one enum in the project. That one we typedef (it contains the channel names of all data we measure and save to disk). We have a small script that fills the enum.

That being said, I like enums to be automatically typedef'd. But I don't like the separate file that comes with it. I don't like the idea of a subvi that cannot run on its own but needs a separate file. If that somehow can be solved, I'm willing to kudo the idea.

[Mythilt]

@JKSH

I make heavy use of state-machines in my code, so a lot of my subVI's have state-enums, which are VI specific.  I'd like to be able to avoid having lots enum_State_Factor1.ctl, enum_State_Factor4.ctl, enum_State_CalcGraph.ctl files in the project.  As it is, I just don't typedef the majority of the state-enums and deal with the issues when I make changes to the code.  To be able to typedef the state-enum as part of the actual VI would be wonderful for me.

[Taylorh140]

Personally I would be happy if they didn't create a control file unless they were used in more than one VI.

For me most of the time I use an enumeration its usually a one off for a state machine or the like, and I tend to drop the enum in multiple cases (as people do) but when i need to add a state I'm screwed if i didn't already have a type def (thank goodness for quickdrop) and I'm sure even the pros run into this mistake now and again. I really do loathe creating a type-def file for these one off situations.

Perhaps this behavior:

When a new enum is created make it a psudo typedef. Any copies made within the VI are linked and if one changes all of them change.

If this is copied to another VI ask if it is copy(to be changed) or to be linked. if it is to be linked ask them to save the typedef file.

[crossrulz]

Taylorh140, what you are requesting is a VI Scoped Type Def.