VI Scoped Type Def

[--thatguy]

When creating a state machine it's often handy to use an enum that lists all your states.  

You then take that enum and make it a type def so that if/when you update the enum (to add or remove a state) throughout the states, all instances of the enum get updated.  

But the thing is, now this potentially simple state machine VI requires this secondary type def file.  No other VIs would need access to this type def so making it a seperate file just shouldn't be necessary.

[AristosQueue (NI)]

> The potential solution was to use an llb, but by the sheer nature of the way the LabVIEW editor

> works with llbs, this functionality is prohibitively time consuming wheras the text-based counterpart is not. 

I need more explanation of this statement. I work with LLBs all the time. especially recently after I opened up the right-click menus through plug-ins that are saved as LLBs. I don't see any difficulties with working with them other than the fact that you can't save a whole class hierarchy into a single LLB because of the name collision problems (which I mentioned above). "Prohibative" is not a word I would use with them at all... they're as easy as using folders on disk as far as I'm concerned ... but my experience is not yours, so, please, let me know what is hanging you up with them.

I realize this is a slight tangent from the main thread, but I think it is worth following up on here because of my stance that the way to address this whole idea is solely by strengthening LLBs and not by allowing VIs to contain anything, types or otherwise.

[X.]

Implement it already.

[iZACHdx]

>I need more explanation of this statement. I work with LLBs all the time. especially recently after I opened up the right-click menus >through plug-ins that are saved as LLBs. I don't see any difficulties with working with them other than the fact that you can't save a >whole class hierarchy into a single LLB because of the name collision problems (which I mentioned above). "Prohibative" is not a >word I would use with them at all... they're as easy as using folders on disk as far as I'm concerned ... but my experience is not >yours, so, please, let me know what is hanging you up with them.

The editor experience is prohibitive - especially in comparison to other file types such as libraries or classes. I would hardly consider it "First Class."

• Editing the LLB is not possible without using the LLB Manager
  • I would want to be able to edit the LLB directly in the Project Window. I don't need yet ANOTHER window open in addition to front panels, block diagrams, project windows, etc.
• Management of the structure inside the LLB - Where are the virtual folders? What about access scope?
• Adding and removing files to the LLB - I can't drag a file from the LLB onto disk and have it removed from the LLB and saved to disk. The opposite also cannot be done - I can't drag from disk into an LLB and have it added.
• What sort of build outputs are possible with an LLB? At least libraries can be built into packed libraries.
• Most of my development heavily utilizes LVOOP so the problems with Classes is far from just a minor inconvenience.

[AristosQueue (NI)]

iZACHdx:

Thank you for the explanation.