LabVIEW Idea Exchange

I find the process of initializing Maps in LabVIEW to be unintuitive and inconsistent with the initialization process for other similar concepts (such as, say, arrays).  After some initial trial and error, the process I've settled into for creating maps is to drop a map constant, and then to drag and drop the appropriate data types onto it for my key and value. I first looked for an Initialize Map VI (which doesn't exist) and then tried to create the constant by wiring up appropriate types to an "Insert Into Map" and creating the constant from there -- but this doesn't work as expected because the terminals don't update appropriately.

What drove me to coming to the forum today though, was that in creating a malleable VI with a map inside of it, I found a breaking point for the "drop constant and drag values into it" approach. Since the map data types need to be dynamic to support malleable VIs, I've had to get creative to get around that...

Unlike building a Packed Project Library, source distribution builds will succeed even if a contained VI is broken. For my use case this is undesirable - a broken VI being included in the source distribution is always user error, and I would like to be notified during the build process.

It would be helpful if the build specification for a source distribution could be configured to fail if an included VI was broken. By defaulting to false this could be added in a backwards-compatible way without breaking any existing build specifications or workflows.

I could write a post-build step that validates the VIs are not broken, but this wouldn't provide feedback until the build is complete. A native solution could abort the build early if VIs are broken.

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

The LabVIEW Viewer would be a stand-alone application that allows for the viewing on VIs for someone who doesn't have a full-blown LabVIEW installation.  It would function similar to how the development environment functions on a 'locked' VI.

I've used 'VI Documentation' in the past, but this viewer would allow for live navigation, context help, drilling-down into SubVIs, scrolling through case structures, etc.