LabVIEW Idea Exchange

Currently, if you select a tunnel, you can only move it along the border of the structure - attempting to move the tunnel perpendicular to the structure border is just a no-op. Instead, I'd like to see this action resize the structure!

The first video demonstrates current behavior, how tunnels cannot affect structure boundary sizing. The second video shows a selected tunnel resizing the structure boundary as it is repositioned.

1. These demonstrations reposition the selection using the Keyboard, but the same principle could apply repositioning a selection with the Mouse.
2. A side perq of this feature is that structures are resizable with fine, granular control using the Keyboard!

Renaming files with F2 or the context menue entry "rename" is easy - as long as the file is a LabView or NI-File. But if it is just a simple *.txt, *.pdf, ... file it is not possible. Please add this function! - thanks.

As part of a review of a shipping product, I want to make sure that all of our LabVIEW-built executables are using the same version of LabVIEW so that we also only have to ship one version of the LabVIEW Run-Time Engine. Everyone I've talked to has given me advice on things to change at export time, build time, or even run-time to know the version of LabVIEW it was built in (e.g. the App.Version property), but what if I want to know the version of an EXE I have already built?

Here are the methods I've tried so far:
1. I created a set of VIs that does it crudely by reading the EXE file in as if it were a text file, finding mention of lvrt.dll, and then scanning back a few hundred bytes to try and find a version X.Y token in there. (Of course this could be done in any language, not just LV). This solution can be automated for my product release's review process, but it would be prone to failure if the EXE format changes or my assumptions aren't correct. I wrapped the solution in one that searches our installation directories for all EXEs and returns all LV EXEs with versions (as they are detected here) and all non-LV EXEs so I can verify that my tool is not giving false negatives on LabVIEW-based executables.

(See attached .zip file for my LV implementation)

2. Run the EXE on a machine with no LV RTE and read the version from the error popup that you get when it launches. Obviously this requires user interaction, and requires launching the executable.
3. Install all LV RTE versions you think the EXE most likely requires. If it launches without incident and stays in memory, you can use Process Explorer to figure out what libraries it has loaded and see which version of LV RTE was called (since the lvrt.dll will be under "<NISHARREDDIR>\LabVIEW Run-Time\<Version>"). Obviously this isn't easily automated either, and requires launching the executable.
4. I tried using Dependency Walker to see what lvrt.dll dependency was found, but it didn't show me anything useful. I'm guessing it's dynamically loaded somehow, and DepWalker can't tell me?

What I'd really like are two things:
1. An LV Invoke Method like "Get VI Version" and "Get VI Editor Version" that works on built applications -- "Get App Version" with the same types of inputs and outputs as (file path input, string version output and U32 version output). An added output to determine platform and/or bitness would be nice, too.

2. An LV RTE property that tells me the Run-Time version in the file's properties. I could potentially automate checking of this via .NET calls or something like that

When you compare two Vis, one with a control, and the other one with the same control but with a change on the test justification (You can modify it by clicking on the dropdown menu of text settings, next to the pause button)

daguero_0-1680115378128.png

If you compare the vis at this moment it only shows this

----------------------------

Difference Type: text justification

As we can see there is missing information regarding other comparissons like label name, object type and detailed description like the following example

----------------------------

Label Name: Label1

Object Type: String

Difference Type: moved

Detailed Description: Changed from "(168,132)" to "(12,71)"

daguero_1-1680115378130.png

Consider that this is a small scenario (only comparing two indicators) where the difference can be found easily, but if you try this with bigger VIs it will have a lot of missing information

The fact that this information is not available is time consuming, eventhough they can be walked manually the record of changes is compromised

I am migrating and updating some of my favorite tools to LV10, and one of the first to make the move is always my Connector Pane Editor.  This is a homemade tool I have had around since LV8.2, which allows me to quickly wire the connector pane in a style reminiscent of the Icon Editor.  I use my version constantly and can not live without it at this point.  I would like NI to adopt something similar for a few reasons.  1) I am a UI pragmatist, and this could probably use a little help in this regard.  2)  It is hard to incorporate tools like this into the IDE.  Right now I use the Tools menu which is ok, but I'd like to get this into the Right-Click menu that we currently use to edit the connector pane.  3) It drives me nuts when I am on a computer that does not have this.

Here is a screenshot of my version and zoom on the right-hand side.

Features I like about my current version:

1) No squinting and carpal tunnel issues trying to land on tiny terminals

2) Auto increments controls, when one control is placed, the target is automatically incremented so the next control is ready to go.  Arrow keys allow you to skip controls.

3) Front panel image shows which control is currently being wired, which one is currently attached to a terminal when the mouse is over it, and is clickable to choose which control to wire.

4) Control descriptions are editable at the same time.

5) Shift-click grabs the currently wired terminal.  If you want to move a connection, Shift-click to pick it up, move to the new location, click to drop.

6) Clicking on a currently wired terminal replaces that connection with the current target, and makes the previously wired control the new target.  Swapping terminals is a two-click process.

7) Optional autowiring, Error In/Out as well as references/paths can be autowired according to my preferred style.

In short, even my crude attempt is an incredible timesaver, I can wire a ConPane in a matter of seconds, without the back and forth trips between the FP and the ConPane with the wiring tool.  A little NI-ification, as well as integration should make it even better.  If it gets screwed up, at least it should be similar to the Icon Editor which can be modified by those who want to badly enough.

The Compare VI tool is immensely useful, except when identifying changes in case statements, where it is easily "confused". Take for example two VIs where the cases in the case statement are identical except that in one VI there is an additional case at the end, or has a renamed case. When you run the Compare VI tool, everything is out of whack. It shows differences between two case that are named totally different, ignoring the other case that is named exactly the same. When this happens, you end up manually comparing. It would be great if the Compare VI tool would ignore the case order and compare the actual case names when doing a compare, much like a text compare tool would. Maybe even make it an optional setting.

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire.  Lets say I have a 1D array of numerics selected and I want to reverse it.  I will select the wire, then invoke QD and type "reverse".  But the first item in the list is actually "Reverse String".  With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.  

This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster).  But we could also use this on class wires that are selected.  A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up.  So this idea could also prioritize functions that are found in the mnu associated with the class.