LabVIEW Idea Exchange

We can easily replace a FOR loop with a WHILE loop and vice versa and most features are retained in a reasonable and expected manner. (For example if there is an indicator wired to [i], it will still be connected after replacement).

There is one annoying exception: The conditional terminal is completely ignored.

For example:

Case 1 (FOR -> WHILE)

We have a FOR loop with a conditional terminal wired to a boolean condition. If we replace that FOR loop with a WHILE loop, we probably would expect the conditional terminal be still connected in the same way. This is not the case. We get a dangling broken wire and a new, now disconnected conditional terminal.

Case 2 (WHILE -> FOR):

We have a WHILE loop and replace with a FOR loop. If the conditional terminal is wired to some real code, it should automatically retain the conditional terminal in the same place. (If the conditional terminal is not wired in the while loop, the FOR loop should not show the conditional terminal).

As a practical example, let's look at my old inverse erf draft posted here long ago. One flaw is the fact that there is no limit on the number of iterations so it might get stuck with a misbehaving function. In the old days, we would add another comparison with [i] and OR to the termination condition (lots of extra code, new loop needs to grow in size). A cleaner solution is to replace the while loop with a FOR loop, leaving the conditional terminal in place as-is, and wire a reasonable iteration limit to N (little extra code (just one diagram constant!), loop can remain at the same size). Here Case 2 would simplify the transition.

SUGGESTION: If we switch loop flavors using the "right-click..replace" mechanism, the conditional terminal wiring should be retained in a reasonable way.

The detailed help link in the LabVIEW Context Help window is a great way to add extra documentation to your LabVIEW code.  However it currently only supports .hlp, .chm, .htm, and .html files types.  This should support many more documentation types such as pdf, txt, doc, .xls, png, .etc, etc.

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!

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

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.

Add ability to install and update NI packages via the winget utility.  This would make it easier to standup new development or test systems. 

Winget has a very user friendly export/import systems that can be used to replicate development installs across multiple computers. 

I think you should be able to build this around the current NI package manager system with some helper scripts.