infoEnum (enum type definition browser)

[Jacemdom]

Hello,

A tool for those who make extensive use of enum type definitions.

infoEnum is a donations supported, LabVIEW VI add-on built to help LabVIEW software designers who build complex softwares using enum type definitions to control the different events and actions occurring in the software. It allows to see which enum values are used were and also find the unused ones easily.

Details here.

[Onno]

Hi!

Thanks a lot for posting this! This is going to be extremely useful for a project I'm working on right now...

I'm not sure about the experiences of other people here, but I keep running into this nagging issue in LabVIEW (2009/2010/2010 SP1). I'm using strictly typed enums for controlling a whole bunch of state machines in my project. Quite regularly, LabVIEW resets enum values all over my project. This of course leads to all sorts of nasty bugs.

I was first able to track this down to certain types of modifications I would make to the enum value list in the typedef; LabVIEW would get confused, and then reset all enums of that type in the project. However, I've also seen cases where there's no clear reason for this global enum reset, or where LabVIEW would only perform this reset in some locations.

I was actually considering to give up on the enums, and switch to Strings; but I'm wary of performance issues that might arise in some tight loops. In any case, this tool may well help to keep all enums in control. Thanks again!

[crossrulz]

I'm not sure about the experiences of other people here, but I keep running into this nagging issue in LabVIEW (2009/2010/2010 SP1). I'm using strictly typed enums for controlling a whole bunch of state machines in my project. Quite regularly, LabVIEW resets enum values all over my project. This of course leads to all sorts of nasty bugs.

Do you see this issue when the enum is not strictly typed (use Type Def instead of Strict Type Def)?

[Jacemdom]

LabVIEW resets enum values all over my project. This of course leads to all sorts of nasty bugs.

I was first able to track this down to certain types of modifications I would make to the enum value list in the typedef; LabVIEW would get confused, and then reset all enums of that type in the project. However, I've also seen cases where there's no clear reason for this global enum reset, or where LabVIEW would only perform this reset in some locations.

I also suffered from enum reset issues. I developed some update rules to avoids such issues.

Always do one action on one item at a time and apply modifications after each update. Example :

1- Change name #1

2- Apply to all

3- Change order #1 to #3

4- Apply to all

5- Delete #5

6- Apply to all

7- Add new item before #4

8- Apply all

[Daklu]

2- Apply to all...

4- Apply to all...

6- Apply to all...

8- Apply all...

One thing to be aware of is "Apply to all" only applies the change to those instances of the enum that are in memory. If a vi that uses the enum isn't loaded into memory (which is not the same as seeing the vi in the project explorer window) when the changes are made Labview applies the changes the next time the vi is loaded. If you've made multiple changes Labview may not update the selected enum value correctly.

[Onno]

Do you see this issue when the enum is not strictly typed (use Type Def instead of Strict Type Def)?

Hm, haven't tried that yet. But doesn't that lead to other typedef issues?

One thing to be aware of is "Apply to all" only applies the change to those instances of the enum that are in memory. If a vi that uses the enum isn't loaded into memory (which is not the same as seeing the vi in the project explorer window) when the changes are made Labview applies the changes the next time the vi is loaded. If you've made multiple changes Labview may not update the selected enum value correctly.

That's a good point. Maybe I should try being extra careful when making such changes, and make sure all my VIs are in memory somehow. Thanks!

[Daklu]

That's a good point. Maybe I should try being extra careful when making such changes, and make sure all my VIs are in memory somehow. Thanks!

The traditional way of doing it is to create a "Tree.vi" and drop every vi in your project on the block diagram. (Don't worry about the broken run arrow.) Then whenever you're working on the project make sure you open the Tree.vi front panel before making any changes. Opening the fp automatically loads all dependencies into memory.

[Jacemdom]

New version