LabVIEW Idea Exchange

Anyone building an executable in LabVIEW probably ran at one point or another into the situation where you exit the app, but the window stays open. So, you do some research and find out that you can call the Quit LabVIEW primitive () or close all the windows in the app to make it really exit. If you add the Quit LV primitive, you then probably encounter this - you test the app in LabVIEW, then when you stop it, LabVIEW suddenly disappears, requiring you to add code which will only call the primitive when you're running as an executable.

So, what if LV had an easier way of handling this?

Here are some options:

1. Add another primitive which will only work in EXEs.
2. Add an input on this primitive which will tell it to only work in EXEs.
3. Add a VI to the palettes which will wrap this primitive and allow the user to select when it's valid (default - only in EXE). That VI can also have an error input. This is the method I use today (the VI is in user.lib), but it would be better if NI shipped this VI.
4. AND MUCH BETTER - executables should exit by default when all visible VIs finish running. Thanks Randy.

We currently need to use for loops to convert between arrays and sets:

This is not a bad thing in principle, but in my opinion there are multiple issues with it:

1. These loops require a lot of space on the block diagram, which distracts from the *actual* code. The for loop provided on the palette in particular is absurdly large (and has a label attached to it). Most users probably won't use it more than once.
2. The same code is used in many places to do the exact same job. This is a strong indicator for reusable code in the form of SubVIs.
3. An empty for loop can confuse users who are new to sets.

I think LabVIEW should ship with malleable VIs to take care of conversions between 1D Arrays and Sets, because everyone who uses sets will need them eventually:

Show the Context Help for packed project library VI terminals. Without it, development suffers. For example, a wire conflict occurs but the nature of the source or sink type is not available for inspection.

I use .ini files for alot of my configuration setups and like to add comments after the key value for future reference and clarity.

The problem is that if you write to the .ini file, all comments formatting (i.e. white space) is removed resulting in a .ini file that looks like a bomb has gone off in it. 

Below is a snapshot of before and after the write for clarity:

Ive spoken to tech support and they confirmed that due to the nature of how the VIs are written this is the default behaviour. For clarity and full understanding I have included their response below:

I've been looking through the source code for the config file vi's and I've found where the tabs are disappearing. During the open config file function, the existing keys are parsed. This includes trimming any whitespace, which is why all your neatly aligned columns with tabs are disappearing, in the general case.

This can be overcome by modifying the file. The config files are all found in <LabVIEW>/vi.lib/Utility/config.llb/NI_LVConfig.lvlib.

In this library you will need to modify "Parse Key Value Pair.vi". Remove the "trim whitespace" function in the false case, which is currently removing whitespace before the comment. This will lead to all the whitespace remaining.

However, this will only work for keys which are not edited. When you write a key, this all changes. At the low level, the "Add Key.vi" is doing the formatting of the key. In here, you can see in the true>true>true case that there is space added between value and comment, which simply reformats the key to have 4 space characters before the comment. You could change this space constant to tab constant (maybe just have 3 of them), which would preserve most of what you are intending to keep. It will be slightly subject to the length of text affecting the tab alignment. If you need to sort this, you could use a bit of code which reads the string length and decides how many tabs to insert.

This method will work, however it is laborious and time consuming. For me personally it would be a great addition if there were a boolean control that allowed me to set whether to preserve the original formatting or not (True by default). You could even argue that there is no need to have the option to turn it on/off, simply preserve the original format by default then edit the original document after if you so wish.

Any comments or thoughts on this would be appreciated.

Regards

Mitch