LabVIEW Idea Exchange

I would like a control/indicator which supports HTML formatting for display and documentation.  There have been a couple of previous similar requests, here and here, but nothing specific to HTML (although jlocanis has been consistent in his comments on these previous requests asking for HTML formatting).

I would envision a control where you enter HTML and can change the display from the HTML to the rendered text easily, similar to the multiple modes available on current text controls.

Why HTML and not just more formatting options?

1. Why reinvent the wheel.  HTML has been around for decades and works well.
2. You can mix fonts, localizations, superscript/subscript, symbols, etc. within HTML, allowing much more flexibility when documenting front panels.
3. HTML is platform agnostic

As has been said in other requests, extending HTML support to captions, labels, etc. would also be nice, but secondary.

The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.

For community solution and examples of these features please go to -> https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Tree-Map/td-p/3972244

This could include also Pretty JSON since XML and JSON are interchangeable -> http://www.utilities-online.info/xmltojson/#.Xc6XjVdKiUk

Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.

Currently in LabVIEW you can have a top-level palette (Programming, Measurement I/O, etc) automatically populate based on .mnu files existing in the folder structure at <LabVIEW>\menus\Categories\.  However you cannot do this with the sub-palettes such as Arrays, File I/O etc.

I propose to allow auto-populating palettes for all LabVIEW palettes so developers can place their own palette within the appropriate LabVIEW palette for their functions.  One example is OpenG and MGI each have a palette of Array functions.  They are currently placed in a top-level OpenG\Array or MGI\Array location.  If we could sync these folders, we could place each of the array palettes under the Programming\Array palettes:

Simply by dropping their corresponding mnu files here:

Thoughts?  Discussion on LAVA that spawned this idea is here.

I have seen a few posts online indicating a couple of changes here and there for LVMerge and LVDiff.  I think the main problem is that we just want it to work with third party SCM tools like Mercurial / TortoiseHG, SVN / TortoiseSVN, RTC (Rational Team Concert), Surround, ect.  The ability to check in and out from project explorer is not quite cutting it.  With more and more developers using distributed SCC products like GIT or Mercurial the ability to merge and diff becomes really important.  Here is a list of what I would like to see in newer versions of LabVIEW and the LVMerge and LVDiff tools that would give us more time to develop code and less time spent managing software.

1. Both LVMerge and LVDiff work ok with a single vi, but not that well when hierarchies are different.  Most SCC applications will only download one file or the files that are different between change sets when merging or differencing change sets.  The basic problem is that in order to diff or merge LabVIEW requires the vi to be loaded which requires loading dependencies.  If the merge and diff tools didn’t require the vi’s dependencies to be loaded into memory then many of the issues just go away.

 I understand the technical challenges in order to implement this feature, but I think it would be a far better approach then trying to write a huge amount of code in order to handle multiple SCC tools.  Even if that code was written the workaround solutions are not pretty.  For example you would have to download both change set’s entire hierarchies to disk and then compare them.  How well will that work with very large projects?  Or with a merge where you need three version of the hierarchy?

I think the better solution is to just make LabVIEW files act like text files when diff and merges are performed.  The information in the LabVIEW file points to dependencies, and if those dependencies’s attributes change then flag them, but LabVIEW should be able to generate the LabVIEW "file" in a vacuum for differencing and merging.  May require caching more information about dependencies then what is currently saved in the vi, but I think that would allow a better merge / diff utility.

2. Support differencing and merging of all LabVIEW file types (projects, xctls, classes, libraries...).  Sometimes the text merge features in some programs don't take into account the complexity of the relationships between LabVIEW files.  It would be nicer to have a visual diff in terms of how LabVIEW treats the file (e.g. how TestStand differences sequence files).

3.  This is more of a bug fix, but improve the merge windows.  I have found a couple of situations where the code being merged is not even shown in the three windows (base, theirs, mine) and I cannot scroll to that location in the code to intelligently perform the merge.

4. LVMerge exe exits right away before the merge is complete.  TortoiseHG thinks the merge is complete for a file when the exe exits so it blows right past all of the other file merges so only the first file is merged.

5. Cover these use cases as differences between change sets when merging and differencing (item 1 solution should cover these):

Setup: use TortoiseHG to difference an entire change set in the repository with the local drive, or merge two change set in the repository.

• Moved files (not just vi's) in the hierarchy
• Deleted files in the hierarchy
• Files added or removed from classes/libraries/projects
• File 1 changed and dependency File 2 changes it's connector pane connection to work with the changes in file 1
• Both new change sets add the same file that the base change set does not contain
• Same as the last item, but added file has a different location on the hard drive between the change sets

There are probably more that I am not thinking of, but that would be a good start.

6. Simplify the entire process by providing a real IDE for merging and differencing files.  I am envisioning something with a hierarchy of views like Beyond Compare.  It would allow you to simplify some actions at a high level, but would give you the power to perform advanced actions.  For example, present a list of differences, types of differences, and the types of merges possible. 

• Maybe some files can be auto-merged
• SCC thinks the files were different but there are only cosmetic changes
• User could choose between a deleted file or a changed file
• Two versions are different but the user knows which one to choose without performing a merge.

The user should be able to have a quick view (no loading dependencies), or double click on the item and a new tab comes up that allows an actual file merge (vi, class, project, ect.).

 I think a tool like that that has the ability to interface with third party SCC tools would be a huge timesaver especially when dealing with distributed environments where merges occur more often.  It may need to stream all of the changes from a tool like TortoiseHG before performing a merge (probably easiest implementation), or rewrite the GUI for managing Mercurial or GIT change sets directly.

 The other option is to say "just use a check in check out central repository SCC", and I would say Phooeey! to that.   After using Mercurial with TortoiseHG for a while I would not switch to anything other then another distributed SCC application...even with the difficulties with the merges and differences, using another system still poses similar problems (sometimes even worse) and the software management in those programs just stifles productivity.  Has anyone ever tried to move a class and its members to a different directory after the code has already been checked into an SCC tool like Perforce?  How about managing a multi-branch project where stable release updates are not only applied to the trunk but to a major feature branch?  Painful...

I think that these changes to the LabVIEW development environment will move us from “writing LabVIEW code” to “software development using LabVIEW”.

It would be great to be able to configure LVMerge options via the command line as described here

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q0000019c3VCAQ&l=en-US

There was a previous proposal to fix this that was closed

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LVMerge-Configurable-Load-Options/idi-p/1282252

Please kudos this so that that it is considered 😉

DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing).  Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up.   An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open.  Many dlls have similar pointers/handles that need to be properly closed.  This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.

A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created.   That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle.   This VI would contain the code to cleanup/close the contained non-LabVIEW references.  Could have other uses, such as debugging. 

I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help.   Please consider it.

The LabVIEW Task Manager is an outstanding tool for debugging LabVIEW Applications. It should be included in LabVIEW in my opinion.