LabVIEW Idea Exchange

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

Idea expansion:

• Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

I just realized that when creating an interface you cannot create property node folders.

You can see from the pictures below that option is missing from interfaces.

You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.

Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.

Here is a use case, which I think is fairly common - it happens to me a lot:

I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).

The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.

Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.

Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?

It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?

It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.

I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.

To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.

A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:

In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.

Notes

• Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
• Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
• This idea is somewhat related to the following idea: "Show node names when dropped" option

History probes are a very useful tool in LabVIEW. However, one improvement can be made to them when working with enums. Currently, the values in enum history probes are returned as numbers, as shown in the picture below:

It would even be more useful if enum history probes returned values in terms of the enum item names rather than the numeric values associated with them, as shown in the picture below.

Using "Edit Palette Set" is cumbersome and painstaking.

Specific use case example:   I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers.     To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.

It would  really nice if we had the ability to generate or easily edit mnu files.  In the example, a simple search and replace of the paths that the functions in the palette link to would work