LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Intaris

Make every created Enumerated type a Typedef

Status: New

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.

10 Comments
X.
Trusted Enthusiast
Trusted Enthusiast

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
Proven Zealot

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

Mythilt
Member

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.

Jon D
Certified LabVIEW Developer.
donkdonk
Member

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
Proven Zealot

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
Active Participant

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

Certified LabVIEW Developer
donkdonk
Member

@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
Member

@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.

 

Jon D
Certified LabVIEW Developer.
Taylorh140
Member

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
Knight of NI

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


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5