LabVIEW Idea Exchange

It would be helpful if the LabVIEW Python node natively supported Python dictionaries as LabVIEW Maps. This would make it simpler/easier to support a frequently use Python structure. You can work around but you have to do extra data preparation/formatting in both LabVIEW & Python. It would be nice if the node handled that converting to list of tuples and building the LabVIEW map or vice versa for us.

I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references.  It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).

I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.

The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).

Could be very nice for scripting.

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.

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”.

This is something a few power users have asked me about. There's no Instrument Driver or VIPM Idea Exchange, so I thought I would post it here.

What if VIPM could manage Instrument Drivers from IDNet?
There are a few key benefits this would offer us...

• download IDNet drivers directly from VIPM 
• track which version of a driver you are using for different projects and revert when necessary 
• wrap up ID dependencies in a VIPC file for use at a customer site