LabVIEW Idea Exchange

Format Into String can become very complicated when you have multiple inputs. I think implementing it in a way similar to the Formula Node could make it much better.

Ideally,

1. naming of the inputs should be allowed
2. the input fields in the string should be color highlighted
3. when hovering or clicking over any of the input or the format string fields, the matching ones should be highlighted in bold or with different background for example.

As a side note, the Formula Node itself could also benefit from the same color and hover highlighting.

It would be great if the invert option is given for all possible Boolean terminals like input and output of Boolean functions, controls, indicators like what we have in compound arithmetic function.

Quite often I find myself running a new bit of code which contains an untested modal subvi somewhere in it's bowels, to find that the when called the modal subvi doesn't exit. Clearly there's a little bug in my code, but now I'm stuck. The modal vi has all the focus of LabVIEW, I can't close the vi, I can't abort the vi. Nothing is accessible, including the Project Explorer window.

Now what I need here is a LabVIEW Running VIs Task Manager, which allows me to simply scroll down a list of open and running vis, and abort the one that's stealing my focus.

It would probably have to operate outside the development environment to avoid being supressed itself, but presumably a standalone executable can link into LabVIEW through the server port and access the list of running vis with server calls.

This would save me from having to use Windows Task Manager and killing LabVIEW (and potentially any unsaved work)

I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 2.1.3.4634 crashed", and I can figure out which source this was).  I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).

However, in order to get the correct Build to appear in my Executable, I must build twice.  The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.

Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this.  I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build.  True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?

Bob Schor

I frequently perform operations on Maps of Objects which hold private data where I do not intend to alter the structure of the Map.

Existing Solution

However, Maps are a bit clunky to work with when operating on all Elements. You must first get the list of all Keys, then use an In Place Element Structure within a For Loop and Shift Registers to operate on each Element as follows:

Potential issues with this:

1. Unnecessary branch of the Map which may not be optimized by the compiler
2. Excessive block diagram editing which slows down the development time involved when working with Maps
3. Potential for syntactical errors due to complexity of this operation

Proposed Solution

It would be great if there were some kind of auto-associating tunnel available to For Loops:

Note that the Key is not modifiable, nor is it even available within the For Loop.

Perhaps the tunnel icons must be changed so they are not confused with shift registers.  I just copied the association icon from the map datatype icons.

This level of functionality is similar to the syntactical abbreviations available in most languages which support maps as a standard data type.  I originally wanted this kind of functionality for Sets as well, however modifying the values may result in structural changes to the set itself due to the uniqueness constraint.  As such, this is only applicable to Map Values within For Loops.

It may not be obvious, but this kind of tunnel would not be available to While loops.

Selection

This option would be available on the block diagram through the context menu items of the Map datatype Input Tunnel to the For Loop.