LabVIEW Idea Exchange

Hi all,

When LabVIEW prompts the user to locate a file and the file is inside an llb or lvlibp, long names of VIs are truncated in the title bar such that the user cannot easily verify which VI was prompted for. This ought to be fixed by allowing users to resize the window horizontally.

Here is an example wherein it is ambiguous which VI is being prompted for. Allowing horizontal resizing of the window would offer a straightforward fix that would help people with waning short term memory capabilities.

The relevant LabVIEW help topic unambiguously refers to this window as "File Dialog Box".

I am not referring to the File Dialog function on the palette.

Thanks as usual!

Mr. Jim

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.

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!

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.

Hi all,

Since the release of the new “Silver” control style in LabVIEW 2011, I had the idea of having a style control on the front panel. You would essentially click the drop down box and it would change all/selected controls and indicators on the front panel to that style.

Take a look at the mock up below.

The idea could be extended to having a style of control that the User could populate, notice the “User” on the drop down.

I hope that you like my suggestion I can certainly see many uses for this.

In case of a front panel with several buttons, a dialog to set the Key Navigation option for all of them would be more convenient and faster than having to open the properties of each button individually.

By default, VI Server uses TCP to communicate between applications.  This stream of data is not encrypted and open to hacking and snooping.  

My suggestion is allow VI Server traffic to be encrypted, perhaps using SSL/TLS  or an AES algorithm.

The reasons are obvious.  There is an increasing number of cyber attacks in industrial control systems.  Many cyber attacks are perpetrated internally, so a firewall or air gap is only so helpful.  And in certain environments (ie military, medical) you can't even consider transmitting data without encryption.  This means VI Server is not an option for many users.

I see that LV2020 now supports SSL/TLS in its TCP functions (see here), so the logical next step would be to make use of this in VI Server also.