LabVIEW Idea Exchange

Hi,

wouldn't it be nice to set the access scope for multiple VIs in the project tree? Currently you have the possibility for using virtual folders. When I right-click on multiple VIs i can analyze them, run unit test, etc. Currently we're building the hierarchy of virtual folders according to functionality and not by access scope.

I searched the ideas but didn't found such an idea. If so, please don't shoot me for a double post.

Currently the only way to set/modify Tcp socket options is by directly calling some system library, as done for example in this post.

This not only causes code difficult to understand ("what does that library call do again?") but also poses problems when you want to use your code on different operating systems: Currently the only way to do this is using "conditional disable structures", and then Labview still tries to load the code used for a different operating system...

Labview should have a standard way to set socket options within Labview code, at least for the most important options (Nagle algorithm leaps to mind...). This could either be done as additional inputs to the "Tcp open connection"-VI, or (much better) using property nodes for Tcp connections.

Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.

Current Method: Property NodeProposed Idea: Invoke Node

The "Convert Instance VI to Standard VI" right-click option on malleable VIs made me think if this technology could be used for debugging otherwise inlined VIs (and therefore also malleable VIs)?

VIs are obviously inlined without their block diagrams, so my suggestion would require two changes:

1) 'Allow debugging' must be settable in combination with inlining in VI Properties >> Execution.

2) LabVIEW IDE and RTE would have to call inlined VIs in different ways, depending on this setting. Suggestion follows:

Running in the IDE

The IDE would now create a temporary unique instance for each running inlined subVI that has debugging enabled. This would allow us to double-click on an "inlined" subVI while it's running, and have that temporary instance open up ready for probing. Settings like the 'SubVI Node Setup' dialog would now also be available for inlined VIs, if they have 'Allow debugging' on. Set 'Allow debugging' off and inlined VIs will behave as today (so no change for any existing code).

Running in the RTE

Executables are built with 'Enable debugging' either on or off (Advanced page of the Application Builder). I suggest that Application Builder builds in unique instances in place of debug-enabled inlined VIs when 'Enable debugging' is on, and bakes in ordinary inlined code when 'Enable debugging' is off. This would allow us to debug into inlined (and thus also malleable) VIs inside executables with remote debugging. Loose VIs called with the RTE would have had their inlined callees compiled with either debug capability or not, depending on their 'Allow debugging' setting as discussed above in "Running in the IDE".

What do you think - would it be nice to be able to debug inlined VIs?

Add "Find All Instances" for polymorphic VIs. Right-clicking a normal VI's icon in the upper-right displays a pop-up menu with quick access to a "Find All Instances" item which helps greatly when navigating code to find all callers, then their callers, etc. However, when a caller happens to be polymorphic "Find All Instances" is not available and the work-flow is broken. Ctrl+F or Edit, Find can be used but the Find dialog must be manually configured: "Search for" Objects may have to be selected if Text was last used; "Select Object" must be set from a looong list of VIs. By that time, concentration is lost.

This is somewhat related to this idea by GregS, but still not quite the same.

The array index terminal of an In Place Element structure currenty require to be wired. It should exactly like "index array" such that unwired inputs behave like the plain old Index Array (an unwired index is the index of the above terminal +1 (recursively). The top terminal defaults to zero).

As an example, here's a simple construct that keeps the N, average, min, and max in a size 4 array. For some reason, the code is broken unless I wire indices 0..3. None of the indices should be necessary and the functionality should remain exactly he same without them.

So one shortcut I really like is CTRL+Shift+E.  This shows a VI in the opened project and drills into dependencies, and libraries to show you where the VI is.  The most common reason for me doing this is to find the library or class that a VI is in, and to find the other members within that library.  One issue I have is if I open a VI that isn't in a project.  This isn't very often but some times I want to work on editing a library or class that isn't part of a project yet and is just some reuse code that I intend on cleaning up.  

When I open a VI that is in a library, but not in a project, CTRL+Shift+E does nothing, but what I think would be nice is if this same shortcut could be used when not in a project to open the Edit >> Browse Relationship >> This VIs Class and open the class to show where the current VI is in the class or library.  Or alternatively this idea could be to make a new shortcut that does open the library or class a VI belongs to, and select the VI in a similar way to the This VI In Project works.