LabVIEW Idea Exchange

Right-clicking a subVI and selecting "Find all instances" is extremely useful. However there is currently no way to filter the results by a particular input or output being wired in the caller VI.

My proposal is: It would be great to be able to filter by a particular input or output, or a particular combination of inputs and outputs, being wired in the caller (i.e. being used by the caller) when using "Find all instances". There are multiple ways of exposing such a filter to the user, so I won't attempt to mock up a design here.

Background

Recently I refactored parts of a medium-size LabVIEW project that I was working with for the first time. As part of the refactoring I wanted to remove an output of an FGV-type subVI with multiple inputs and outputs, because I suspected that that output was unused by any of the callers. Using "Find all instances" I found around 60 instances where this subVI was called. I had to Ctrl + G through the results list and check that the output I wanted to remove was not used in any of the callers. This would have been simpler if I could have set a filter condition to this effect, as the search would have returned only those callers that were using that output. In this case, the search would have returned 0 results, thus confirming that the output was unused.

Side-note: You are probably thinking "You could have disconnected the output terminal from the connector pane, and used the Error List (broken run arrows) to find the broken callers." That's what I intended to do before I realised that virtually all of the caller VIs were dynamically called VIs. Therefore those VIs being broken wouldn't have broken the main VI of the app. I put those dynamically called VIs into the disabled case of a Diagram Disable Structure such that they were loaded in memory and "Find all instances" would search inside them.

Thanks

Background

This idea is derived from the following idea: Front panel controls and indicators should be genuine after being replaced with control or indicator of different style . Please read that thread for background.

Problem
There are three ways to replace front panel controls and indicators:
1. Right-click the control or indicator, select Replace, then select the select the object to replace with.

2. Select the control or indicator, press Ctrl + Space to bring up QuickDrop, search for the object to replace with, then press Ctrl + P.

3. Select a control or indicator and press Ctrl + X. The control will disappear from the front panel. Select another control or indicator. Press Ctrl + V. The second control is replaced by the first control.

The first two methods preserve some of the look and feel of the original object. For example, when replacing a Modern-style string control with a classic-style string control, the end result is a control that looks like a mixture between the two styles. This may or may not be desired behaviour.

The third method does not preserve any of the attributes of the object that was replaced. The end result is a control that looks exactly like the control that was selected when Ctrl + X was pressed.

Both behaviours can be desireable in different situations, and it's good that there are ways to achieve both. However, the third method is not easily discoverable.

Proposed solution

A more intuitive and discoverable solution could be: After right clicking an object, selecting Replace, and selecting the object to replace with, a two button dialogue message could popup. The message could ask something like "Preserve attributes?" The buttons' Boolean text could be "Yes" and "No".

Ideally the same popup would appear when using the QuickDrop Ctrl + Space, Ctrl + P method.

This would:

1. Enable the user to select either to preserve attributes or not, depending on their intention at that particular moment. (the same user may prefer either behaviour at different times)

2. Increase awareness that two behaviours are available

Thanks

When we try to replace a small function in the function palette its easy... But while trying to replace a VI which is inside some sub palettes and sub palettes its really time taking..

So while replacing a VI its good to pin the function palette and select the item for replacing.

I hope this has not been posted earlier.

                  Existing    

                              Suggested

It would be great if Labview had saveable views. I sometimes find myself looking at one part of a block diagram, and then switching back to another part of it to do some work. It would be great if I could just save both views (maybe with shift-F1, shift-F2 etc..) and then recall them (maybe with ctr-F1, ctr-F2 etc..). Sometimes it's annoying to have to keep scrolling through case structures or across my block diagram to get back to the code I want to look at. If I could just find it once, save the view, and then go back to it with a shortcut key combo, it would save me a lot of time.

I got this idea from RTS games (specifically Startcraft 2). In that they let you quickly jump to different places of the map with shortcut keys. I find myself wishing Labview had the same functionality. (for an example: http://www.youtube.com/watch?v=SKuqC1FpGuU Watch from 1:00 to 1:36 or so.)

Thanks!

When I start LabIVEW, it will eventually ask me to log into my SCC (I use Perforce) as part of the startup process.  Unfortunatly, LabVIEW requires that I type my password into the Perforce login dialog and then Perforce responds within 60 seconds or this will fail and I will get the following dialog:

So, if I start LabVIEW and then go off to do some other task and miss the window, I get this error.  If I then open a project, it is not linked to my SCC system and none of the SCC status indicators show up on the project items.  The only way to fix this is to close LabVIEW and reopen it.

All I am asking for here is a 'RETRY' button next to the 'OK' button so I can get a second chance at this.  It is a small thing, but it would make my life much happier...  So, please vote for this idea, even if you don't have the same problem. 

If you try to build an executable of a VI that only uses a static VI reference to call a subVI - you must either select

1. "show FP on call" in the referenced subVI

OR

2. you must include a property node or reference on the block diagram of the referenced subVI

I believe "always including" the subVI in the build spec works as well.

Failing to do so apparently results in the builder to NOT include the called vi's front panel with the build, resulting in the subVI failing to function in the executable environment.

While that all makes "sense" - it is unintuitive and the workarounds are not ideal.

The application builder should look at static VI references when looking at the build and automatically include the referenced VIs in the build.