LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Make every created Enumerated type a Typedef

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.

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

Trusted Enthusiast

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


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.

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.

Trusted Enthusiast

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.

Active Participant

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




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



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.





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.