LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (2)

The idea is to decouple the icon editor from LabVIEW so users can create their own. The intention is to make it easier for people to distribute their own icon editors by only having to place code on disk and modifying an ini token.

This would mean modifying lv_icon.vi so that it contains nothing but a launcher that would load the new icon editor from a path specified on a LabVIEW INI token.

There will be a default plugin that would hold the current icon editor, the path to the default icon editor would be a part of the LabVIEW ini file on LabVIEW install.

I created a working prototype that does that here.

I want to make sure this idea gets traction before going further with this.

Providing additional Context Help information on Controls that contains information as to their "type" (Classic, System, Silver, etc.) as well as their font, font-size, and control-type (indicator, ring, enum, etc.) would be useful. The utility of this is obvious if you have ever had to modify/update an existing GUI and want to maintain the look and feel when adding new controls -- this would allow you to easily see what was previously used for the existing controls on a GUI. This "verbose" information could possibly be turned on/off as a Tools->Options->Front Panel setting.

View All (2)

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)

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

View All (3)

Check out this nice readable diagram:

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either.

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

Here is a simplified example to illustrate the problem (see picture).

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course :)). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

Smaller Event Ref Constants

View All (7)

API for NI web server

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

View All (2)

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.

The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

View All (1)

Enum History Probe Improvement

View All (2)

Add QControls to LabVIEW Core

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.

I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

Font size standardization

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

Idea -->LabVIEW should also standardize here!

View All (3)

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)

View All (2)

LabVIEW Idea Exchange

Align objects should not align increment/decrement buttons

Allow user to override the icon editor with their own version

Front Panel Control Context Help: Show Control Type

Improve cluster reorder and autosizing

When closing project or quitting LabVIEW, Abort VIs dialog should list the VIs

String Constant becomes Empty String Constant when empty

Show subdiagram label and/or preview in Rearrange Cases window

Disallow changing the label of control references and implicit property/invoke nodes

Drop-downs for Selecting Conditional Disable Structure Options

Break bad wire branches, not the entire wire!

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

Smaller Event Ref Constants

API for NI web server

"Enumerated Variant" Data Type (like Rust and Zig have)

Enum History Probe Improvement

Allow Wire Labels to Dictate Name Inheritance in Bundles

Add QControls to LabVIEW Core

Font size standardization

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

Some indication that a string control isn't showing the entire string.