LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Visual Aides - Numeric Separators

I'm totally on board with Embedding Labels for Property and Invoke Nodes! Here are some additional improvements to those nodes:

Property Node Concepts

Scripting and Invoke Node Concepts

Most importantly, the banner now more closely resembles a Static Control Reference.
The directionality arrows are a pixel width's larger - more distinct, and matching the size of the new LV2010 Local Variables.
The node banner is the same height as the unlinked property node.
Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
Scripting properties/methods are now more distinct. Currently, the small node banner inherits a few pixels of light blue distinction if any one property on the property stack IsAScriptingProperty. Proposed, shading will be applied on a per-property basis, allowing better visual distinction and a more coherent choice for what to shade.

Discussions/suggestions/insults/questions encouraged in comments section!

View All (7)

Native support for IPv6

View All (2)

It would be useful to be able to disable the handling of a single Event Case in an Event Handler Structure. Note that this is distinctly different from merely Diagram Disabling the contents of the Event Case; using that method, the Timeout event case will be reset, and additionally program execution will continue past the Event Handler Structure (in the example below, continue to the next iteration in the While Loop).

Here's an example of what a Disabled Event Case might look like - the Event Structure and contained code is "washed out" as if Diagram Disabled - additionally, the disabled event in the list of Event Cases is struck-out and in italics:

And here's a proposal for how one might disable a given Event Case, using the context menu that pops up by right-clicking the border of the Event Handler Structure:

View All (6)

One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:

The request:

The thickness of splitter bars can be resized through the front panel at edit time, but this property is not exposed through property nodes. Why not expose this?

Background:

I use splitter bars all the time for resizable GUIs. They're also cumbersome. Many of the feature improvements I'd love to see have already been captured on this forum. In the mean time, I've got tools for automating what I can -- but I've hit a dead end when it comes to resizing the splitters programmatically. This requested property node doesn't exist and pre-sized splitters can't be copied from template VIs using scripting because the "Move" method throws an error.

I would like to be able to create executables that don’t require the runtime engine in LabVIEW. Perhaps a palette of basic functions that can compiled without the runtime engine and an option in the application builder for that. I routinely get executables from programmers that don’t require a runtime installation. I just put it on my desktop and it runs. It would be nice that if I get a request, I could create, build, and send them an exe in an email without worrying about runtime engine versions, transferring large installer files to them, etc.

View All (3)

In general I would like to see LabVIEW more in line with the OS GUI standards. We have dialog controls and colors, however they are not set up to be the default choice - and we lack other GUI elements like status bars, notify icons, child windows etc. etc. A large part of LV-programmers' time is spent on ways to get LV to mimic what users will recognise and therefor intuitively understand.

In this case I simply miss the "sort glyph" that indicates that a table or listbox is sorted based on a given column and in which direction.

I imagine we could show or hide this and set its direction with a property node...It would not handle the sorting (although that would have been neat as well - if you had an in-built sorting that just needed to know a few parameters about the column data to do the job)...

View All (1)

Shrink-Wrap Structures

Often, when modifying code, I need to reduce the size of a structure due to removing code. If I have a nested structure system (e.g. event structure in a case statement in a loop), this can get very tedious. It would be nice to have a "shrinkwrap structure" functionality on the right-click menu as a counterpoint to the autogrow. This would be an action that would reduce the structure size to something a bit bigger than the largest contents. An option to set how much extra space to include would be nice.

View All (4)

View All (1)

View All (3)

This is one of those existing "features" that I cannot understand, no matter how long I ponder why it is implemented this way. (WHY!!!?????). Somebody must have consciously programmed this behavior in the early days of LabVIEW, but I simply don't get it. 😉

Try the following yourself and you'll see what I mean: 😄

Create a structure (For loop, while loop, case, event, etc) with a few tunnels.
Select one of the tunnels, and, using the arrow keys move it towards one of the structure corners.
Observe: As soon as we move within a few pixels of the corner, the tunnel jumps to the corner and can no longer be moved with the arrow keys alone.
To move it away again, we need to grab it with the cursor using the mouse and move it at least a few pixels away from the corner or use "shift-arrow" to move it by a bigger step. THis should not be necessary.

Idea: There should be no such stickyness!

IF a tunnel is moved towards a structure corner with the arrow keys, it should simply stop moving at the corner and we should be able to move it away again by pressing the opposite arrow key (or the arrow key following around the corner by 90 degrees)

Allow a general purpose "on Save" hook

and is a more general request.

Have the ability to run custom scripting code on a save event.

What problem does it solve?

For me personally, I am working on an autoformatter. It would be nice to run that everytime something is saved. Right now I have to monitor the source folder from outside LabVIEW (using Python) and then use G-CLI to run my formatted. I'm sure there are probably other ways to do it and an onSave hook seems like the best choice.

I'm sure there are plenty of other use cases. Perhaps some kind of linting or enforcing some sort of style guide. ie if you save a VI without a description, it won't let you unless you enter a description. Perhaps even every time you save a file, run some unit tests?

Ideal Solution

Ideally the scripting code would have access to the reference of the thing being saved. The easiest thing to envision is a VI, but why not also classes, libraries, the project itself? Maybe also some indication of what triggered the save. Was it a saveall, a save all this library, etc. Maybe if it is a saveall, you get a list of all the things being saved, before anything happens?

The IDE would then wait to continue until the scripting code completes, maybe even failing to save on an error or a boolean - not sure if that is the best behaviour as in a bug in your scripting code could cause you not to be able to save - so maybe some way to override the hook?

Maybe include a way to autogenerate a VI with the correct connector pane.

Maybe it makes sense to generalize this to add more hooks into LabVIEW? Perhaps a call to update the project provider to something more usable/less user-hostile?

Abort All VIs in Project

When improperly stopping a project that has launched asynchronous vis set to fire and forget, you end up with classes and libraries that are locked.

There seems to be no way of unlocking them other than to close the project. There is an idea to abort called VIs when the parent stops but from the lack of kudos and by reading the comments it doesn't seem like a good one.

I know about and use the Abort.vi but it does not work in this case. The dropdown is empty:

Not even the LabVIEW Task Manager can help.

My idea is to have a button that does whatever closing the project does when it unlocks the class or library. Maybe this means it transparently closes the project and opens it again in the state it was in when the button was pressed. I don't know.

I know there are some similar ideas but as far as I can tell this is not a duplicate.

Change class <-> interface

It would be useful if QuickDrop supported a way of dropping multiple instances of the same item in one go. It is sometimes desirable to do so. For example, we may want to drop three numeric constants in one go.

1 (edited).png

The QuickDrop action above would result in three numeric constants being dropped, as seen below.

2 (edited).png

Selecting an error wire, then executing the sequence: Ctrl+Space >> typing "rn" >> increasing the Number of Items to x3 >> Ctrl+I would result in three property nodes being inserted into the error wire, as seen below.

4 (edited).png

Notes

It would be great if the multiplier could be typed as part of the QuickDrop search string. For example, typing "rn x3" or "x3 rn" would then drop or insert three property nodes. This would mean that the whole action can be done from the keyboard, which would be quicker. However, it seems difficult to implement due to the search string needing to be intelligently split into two parts.
Perhaps a much easier implementation that would be almost as quick would be to type "rn" >> press Tab (this would tab to the "Number of Instances" control) >> type "3".

Thanks

View All (1)

Many or most VIs that ship with LabVIEW have their protection set to Unlocked (no password). The screenshot below shows a selection of such VIs.

It would be much better if the protection of vi.lib VIs was set to "Locked (no password)", to prevent accidental modification.

It seems very risky for built-in VIs to be open to modification, especially to accidental modification.

Scenario 1: Developer A is developing an application on their machine which contains modified vi.lib VIs which were accidentally modified as part of work on previous projects. They build an application which passes validation and starts to be used in production. All of the developer's source code is committed to a source code repository. Developer A leaves the company. Six months later Developer B is asked to pull the code from the repository and add a minor improvement. The application behaves very differently when Developer B builds it on their machine. A long and complicated troubleshooting session later, Developer B concludes that the different behaviour was likely caused by modified vi.lib VIs on Developer A's machine. Developer B cannot be sure, because Developer A's machine was wiped when they left, so there is no way to unequivocally prove the conclusion.

Scenario 2: A team of developers builds a test system for a defence application. The code is completed, and the test system is put through a thorough commissioning and validation process that involves testing dozens of known good units and known bad units. The validation process takes three weeks to complete. Management plans to not have to run the whole validation process for future minor changes. Instead they will ask the development team to perform code reviews and record notes for each minor change. Revalidation is not necessary if the code reviewers agree that the changes are non-functional, for example, the wording was changed in a dialogue message, or a logo was added to the UI. This sounds like a great plan, but is technically unsafe. Strictly speaking the whole revalidation process would have to be rerun, even for minor changes, due to the fact that not all of the source code is visible in the repository (there is uncontrolled source code in vi.lib that could have been modified in between builds).

Essentially I don't think it's safe for an app to contain source code that is not visible or tracked in a repository.

I can't think of a simple, quick solution to the concerns above, but having all vi.lib VIs set to "Locked (no password)" could be a quick first step towards reducing the likelihood of this issue. Developers would at least have to consciously edit vi.lib VIs, rather than doing it accidentally which can happen now. Of course, a malicious actor could still wreak havoc by editing a few inconspicuous vi.lib VIs.

The risk would be reduced further if the vi.lib VIs were password-protected. This would come at the expense of not being able to view the source code of native VIs, something which I find useful. Therefore, I personally would prefer "Locked (no password)" to password-protected, but I might prefer password-protected to unlocked.

Similar concerns apply to non-NI third-party libraries that install in vi.lib, user.lib or instr.lib, for example the extremely useful OpenG libraries. These too are examples of uncontrolled source code. For this reason some developers I worked with preferred to copy the OpenG and other libraries into the project repository (this involves a tedious job of opening each library VI and relinking it to the other library VIs in their new location).

This idea is similar but potentially easier to implement than the following idea: Make the VI's from the "vi.lib" Read-only - NI Community

Thanks

View All (3)

LabVIEW Idea Exchange

Visual Aides - Numeric Separators

Further Property and Invoke Node Improvements

Native support for IPv6

IMAQ Vision: Connector Panes everything except 4x2x2x4. Please do it consistent.

Ability to Diagram Disable ("Comment Out") a single Event Case in Event Handler Structure

Snap text boxes to an integer multiple of text height

Expose Splitter Bar Width/Height Property through Property Nodes

Build executibles that don't require a runtime engine

Sort arrow in column headers of tables and listboxes

Shrink-Wrap Structures

Mass Compile Should Optionally Override Save Version

Always break Unbundle or Bundle by Name when the item in the cluster is removed.

Consistently expose nested data in Property Nodes

Concatenate primitive with an option of 'concatenate to new line'.

Make structure corners non-magnetic for tunnels.

Allow a general purpose "on Save" hook

Abort All VIs in Project

Change class <-> interface

Drop multiple item instances in a single QuickDrop action

vi.lib VIs should be set to "Locked (no password)"