LabVIEW Idea Exchange

It would be really nice if you were able to resize properties dialog boxes for controls, indicators, constants, and other nodes on a front panel or block diagram. Sometimes the information entered in a dialog is larger than the allotted space. Fortunately, in those situations, there is usually a tip strip that shows all of the information rather than just the visible portion of the information, such as shown in the enum properties dialog box picture below. To make all information visible, it would be great if properties dialog box windows were resizable and the contents of the tab control pages automatically scaled with the size of the dialog. It would also be nice if pages containing objects with columns (e.g. multi-column listboxes, etc.) allowed the columns to be resized as depicted in the picture below. 

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.

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

This is an idea I've been working on for a while. It's time to let others start evaluating it. 🙂

 ^ I included the above for Dmitry Sagatelyan and similar folks who have asked me for these things over the years so they know the mindset to use when evaluating the idea. But it's written up below for LabVIEW users who only know LabVIEW as it stands today (Q3 2024).

Feedback and questions welcome. 

Open the VI Properties dialog when the Control key is depressed and the VI's icon in the upper right is double-clicked.

Right-clicking the icon shows a pop-up menu with VI Properties, Edit Icon..., and Find All Instances. Double clicking it opens the icon editor.

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.

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.)