LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.

90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:

Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
You could more easily get to the BD of VIs running in a subpanel.
It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.

Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).

This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

Regards,

Raphaël.

View All (6)

Bug replication steps:

Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
Connect an indicator to a VI's connector pane.
Right-click the indicator and select "Change to Control".
The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).

Notes

Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

1 (edited).png

View All (2)

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

Dynamic Probes for Class Data

Class data is painful, if not impossible, to properly probe when debugging LabVIEW code.

It doesn't need to be this way. Every other programming language I've worked with allows viewing this type of data when debugging.

Currently, by default, you only see probe data based on the wire's edit-time class definition, not it's actual runtime class instance. It would save me weeks (literally) a year if I could simply place a probe on a class wire and view the internal class data of the runtime class, including all levels of inheritance.

I realize it's not a small ask since the probe GUI would need to be dynamic (as data type/GUI elements, not just values, would need to be updated when probe is hit.)

The default Data Directory path is set to "%Userprofile%\Documents" under windows.

This is fine regarding custom probes, settings etc, but problematic when it comes to the compile cache and other "runtime" files.

In our corporate setting, this folder is always synced with onedrive AND with the roaming profile. So one problem is, that it bloats the synced volume, which by it self is annoying. But it often leads to corrupt files when onedrive blocks them or writes them in the wrong moment.

So our workaround is to set this path to %programdata%\LabView Data. This, however, brings new problems, since now all users need write access to this folder.

I think a better way would be to save the folder under %localappdata%, but this can not be done with a symblic path and must be defined static, so it works just for one user.

Solution:

Provide a symbolic link to the %useroprofile% or %localappdata% folders. Additionally it would be nice, if the cache target folder could be seperately defined.

View All (4)

"Find" -> "Class Constant" option

Currently the quickest way to open a typedef is right-click >> Open Type Def.

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Notes

The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

View All (2)

Idea:

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

Reasons:

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

To achieve this, I found 2 techniques:

1. Replace by a temporary Control file:

- Create a new VI of type "Control VI";

- Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

- Save the .ctl file to a temporary path;

- Use method GObject.Replace with parameter "Path" on the old control / constant .

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

2. Recode the Replace method from scratch:

- Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

- Copy all relevant properties from the old control / constant to the new one;

- Reconnected its terminal to the wire on the block diagram if needed;

- For a control, relink locals, linked properties nodes, linked method nodes, references;

- For a control, reassign it to the connector pane if needed...

- ...

- Delete the old control / constant.

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

Regards,

Raphaël.

View All (8)

Auto-expanding nodes

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

Start wiring the new error, then click on the merge error node.

LabVIEW expands and connects the error wire

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

View All (1)

Add Revolution Unit

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

Essentially, what I would like is a Type Specialization Structure that works backwards.

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

Simple example of Select

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

It would be useful if a "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style") option existed when pasting text into control and indicator labels, captions, or values.

Example

Screenshot 1: A GUI element (control or indicator) with a custom, non-default label and value (contents) font style.

1 (edited).png

Screenshot 2: The text "Hello World" was copied (Ctrl + C) from Notepad and pasted (Ctrl + V) in the middle of the label. The newly pasted text is inserted using the default font (Application Font, 15 pt, black). There is no option to paste using the destination font style. The developer now has to waste a few seconds reconfiguring the font. The same result is obtained whenever the text is copied from an external (non-LabVIEW) application, regardless of the application (Notepad, Microsoft Word, Excel).

Screenshot 3: The same situation occurs when pasting into a string indicator.

Combined 3 and 4.png

Screenshot 4: In Microsoft Word, it is possible to select the "Keep Text Only" option when pasting text. In the screenshot below, notice how "Hello World" text from the second row obeys the destination style when it is pasted into the first row. A similar functionality exists in Microsoft Excel and is named "Paste Values".

6 (edited).png

Notes

The current behaviour, where the text is pasted using the default font style, can be useful in many (maybe most) situations. I am not asking for the current behaviour to be removed. But it would be useful to have the option to select between the two behaviours.
When the text is copied from LabVIEW, the pasted text maintains its source formatting style. This can be useful, but again, it would be useful to be able to select "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style").

Thanks!

View All (3)

Disable Diagram Zoom

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

BD-Only VIs would be beneficial because:

They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
They would reduce the developer workload, thus making developers faster.
They would reduce the surface-area of the codebase.
They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

Notes

I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

View All (4)

Big clusters that go beyond the limit of the FP are annoying, especially to resize them automatically and reorder the controls.

Here are a couple of improvements that could be made:

"Reorder controls in cluster..."
- Allow user to scroll while re-ordering the controls to have access to all elements instead of having to do it in multiple time.
- Shortcuts like Escape and Enter should respectively cancel-exit and validate-exit the reordering phase
  These are pretty standard shortcuts and already widely used within the Labview environment
"Autosizing"
- Autosize to "Compact". Where instead of aligning all element vertically or horizontally only, they would be in the "most compact" (to be defined) possible configuration to simplify the access to all info in the cluster.
  For instance compacted in a square way, sorted by class (Booleans/numerics/strings etc.)
  I understand that this one might be more complex, but it would be really helpful in my opinion
- Less important (to me): In Edit Mode, in case a cluster is autosized to "none" and some items are hidden outside for whatever reason, the developer should be notified somehow. For instance the same way than for strings
- (In the same case than above, allowing scroll bars could be interesting in some situations.)

-Vincent.

View All (4)

LabVIEW Idea Exchange

Make the default behavior of opening a VI open ONLY the block diagram

Make "Match Regular Expression" inlinable

Fix bug: "Change to Control" should obey "Connector pane terminals default to Required" setting

Show a different broken arrow when the VI doesn't have errors itself.

Skip dividers in listbox when navigating with the keyboard

Dynamic Probes for Class Data

Actually stop loading the project when pressing the stop button

Allow Default Data Directory relative to User Profile

"Find" -> "Class Constant" option

New gesture: Ctrl + double-click on typedef should Open Type Def

Method to replace a Control/Constant from a template object in memory

Bundle to automatically name Static VI Reference element as for other references

Auto-expanding nodes

Add Revolution Unit

Generalize backwards propagation technology - Backwards Type Specialization Structure?!

Give me a “modal when called” Front Panel / Window behavior or I will Kill LabVIEW (taskkill /f /im LabVIEW.exe)

"Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style") option when pasting text into control and indicator labels, captions, or values

Disable Diagram Zoom

Block-Diagram-Only VIs (VIs without a Front Panel)

Improve cluster reorder and autosizing