LabVIEW Idea Exchange

Wire a Case Structure with an enum. Now pop up on it and select "Add Case For Every Value." In today's LabVIEW, this adds new frames to the structure so that every enum value is handled by a unique frame. This makes creating the structure initially easy, and it gives you a way to walk through and make sure that you've filled in code for every frame. But today, the Case Structure has includes the "Default" case when the Case Structure is first wired. That is done so that wiring a Case Structure with an enum does not result in a broken VI. When a programmer provides a unique case for every value, the Default state is now redundant, and the only thing it does is create the potential for error if you ever add to the enum. Thus I would propose that if you use "Add Case For Every Value", then LV should remove the Default tag from the first case.

Currently the only image formats still commonly used today that can be imported into custom controls are non-scalable bitmap formats. The only supported vector formats that I know of are WMF and EMF, which is almost never used anymore to my knowledge. Even worse, it doesn't support features now expected in vector formats, such as gradients and alpha transparency. So if you're developing a custom control, you have to either use an antiquated format or a bitmap format.

LabVIEW 2011 introduced the new Silver control set, which to my knowledge still use LabVIEW's internal PICC format, which is completely undocumented. Rather than adding gradients and other new features to this private, undocumented format and using that, it would have made a lot more sense to add support for SVG, a modern, full-featured vector format that is commonly used, and used that for the Silver controls.

Not only are the two vector formats LabVIEW supports ancient formats, but their inclusion almost seems like an afterthought. Imported WMF and EMF images aren't anti-aliased like the Silver controls. Because of this, it's practically impossible to create any modern-looking custom controls that look good scaled unless you don't want any diagonal lines or curves, in which case you might as well just use a bitmap.

Sorry for the abrupt end!

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:

Here's the order within prebuild vi:

The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.

I suggest that the order in pre/post build VI should be:

first - startup.vi

following: always included vi's in the same order they appear in the project window.

Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.

In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.