LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Certain keyboard shortcuts are standard across operating systems and applications. When doing text entry, LabVIEW implements ctrl-c, crtl-v, and ctrl-arrow keys for text selection and manipulation, but does not allow ctrl-a. I have implemented this for string controls. 

 

I would like to see this be the default behavior for all text entry. 

 

In LabVIEW, ctrl-a currently selects all objects on the FP or BD. But when the cursor is in an active text field, ctrl-a should select all text in that field. This should include strings, tables, graph labels, control labels and captions, numeric controls and indicators, free labels, and so on, and should work in development and at runtime.

When running NI web server, the domain URL of the server will always redirect to the NI web server (or Systemlink) login page. Every Labview-built web application/webservice has a name and therefore must have a path (like: https://example.com/mywebapp)

I would like to be able to set a default redirect in the NI Web Server configuration to redirect the domain url to the default web application on that server.

 

It can probably be done in some Apache config file, but those a really managed by the NI web server configuration and are easily corrupted. My forum post about this issue has not yet been answered.

Idea:

 

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

raphschru_0-1732660843348.png

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.

If different libraries are created by different manufacturers, the same error code can occur multiple times and each has a different meaning.

If you include a project code (unique UID) with the error code, for example, it is possible to provide a unique error message for different program code origins.

 

 

1) Bring to Error Constant a Tag for the Project

 

michaeln_0-1731616848772.png

michaeln_1-1731616959219.png

 

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. 

 

Ryan_Wright__2-1731433895037.png

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.

If I'm not mistaken, there currently isn't a single function that deletes a certain number of characters from a string. This can be done in a variety of ways using existing string functions, such as the example shown in the picture below. It would be really nice if LabVIEW contained a Delete From String function with offset and length inputs as illustrated in the same picture below. If you didn't wire up the length, maybe it could delete the remainder of the string and maybe an unwired offset could default to 0, similar to the String Subset function.

 

Ryan_Wright__0-1729872792549.png

 

Bundle automatically names cluster elements for some references but not to a VI.

dwb_1-1729527929738.png

LabVIEW 2020 32bit (English), installed on Windows 10 (French).

 

I have noticed some small inconsistencies in the localization and formatting of the "File Dialog" and its subdialogs.

 

Let's say you have a "File Dialog" express VI configured in mode "File, Existing".

The main dialog and the "non-existing file" subdialog look like this:

raphschru_5-1729430452566.png

Here I've put the parameters in [square brackets], of course it is the developer's duty to localize them.

For the rest, except for the "All Files" pattern label (which should be "Tous les fichiers" in my case), everything is correctly localized and satisfyingly formatted.

 

Now let's compare with a "File Dialog" express VI configured in mode "File, New".

The main dialog and the "replace existing file" subdialog look like this:

raphschru_4-1729430298672.png

The "replace existing file" subdialog is not localized and its format is not consistent with the "non-existing file" subdialog.

For the subdialog's title, it should be the [Prompt] as well.

For the file name, it should be the short file name (and not the full path). This one is my personal preference but both subdialogs could display the full path as well, as long as it is consistent.

 

Regards,

Raphaël.

Error wires can be passed into most boolean logic in LabVIEW.

 

Except...they can't be passed directly in as the condition for conditional tunnels:

_carl_0-1729004322300.png

For consistency, this should be allowed.

 

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.

I have a habit of putting an enum with a digital display visible in each of my case structure frames controlled via enum.

 

It has become second nature already. Today I stopped and wondered why we can't simply include a digital representation as an "[X]" appended in the visible selector.

 

So here I am asking for it.

 

Intaris_0-1728572984028.png

 

 I believe the number and age of "New" ideas on this exchange renders the word meaningless. I just Kudoed an idea that was 13 years old and marked as "Status: New". This idea would be in middle school; that doesn't sound particularly new. Inaction on an idea after some amount of time should automatically trigger some other status. 

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

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

 

raphschru_0-1727975484834.png

 

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.

The current behavior of a zero iteration For Loop with data that passes through it is shown below. The value passed out of the loop is the default value for the data type rather than the data itself.

 

Ryan_Wright__0-1727296278285.png

 

If you do not want this behavior, you must replace the border tunnels with a shift register. My suggestion is to change the current behavior and instead pass through the actual data rather than the default data type value if a For Loop iterates zero times. Many LabVIEW developers, especially newer ones, are not even aware of the current behavior, which can lead to bugs in software using For Loops.

 

Obviously the picture above is a contrived example, but this situation can occur quite easily if an auto-indexed array is wired to the left border of the For Loop and the array is empty at run-time with other pieces of data being passed through the loop.

When typing a path in the Terminal (Linux, Windows or macOS) hitting the table key does an auto-complete, this is extremely useful.

 

I wish the Path control and - let's dream - the path constant would behave the same.

 

It's probably only applicable to absolut path values.

 

I've made a QControl that does that, it's a bit basic but it does help, I might post it GitHub if there is interest.

Some very useful properties for UI manipulation on graphs and charts do not exist. This makes it impossible to make very dynamic UI's with variable number of plots or dynamic resizing in panels.

It is possible to set Legend.number of plots and Legend position. It is not possible to set:

Graph palette, scale legend or cursor legend position. This makes resizing graphs very limiting.   

Further, it is possible to programmatically create a custom legend.  However it is not possible with cursors because there is no property available to get the current cursor values. Please can we have cursor.values[] and cursor.legend.number of rows

 

 

Online version of LabVIEW 2024 Q1 Help -> LabVIEW Help menu item only points to the LabVIEW Programming Reference and NOT to LabVIEW User Manual.  This means that searches for topics like: "LabVIEW Style Guide" or "Memory" or "Performance" inside LabVIEW do not point to these topics inside the LabVIEW User Manual.  Currently to access any of these topics it is necessary to do an internet search which yields results in the LabVIEW User Manual.

What is really nice about the database toolkit is that "database SELECT" variant data can be cast directly into an (array of) cluster using the "database variant to data" function.

aartjan_0-1725964773106.png

However, it cannot cast MySQL enums to Labview enums. By default, MySQL returns the enum string, not the underlying integer. As soon as the casting function encounters a string to cast to an enum, it fails to convert all following data.

My not so elegant workarounds:

- cast the enums in SQL and use "database execute SQL" instead of "database SELECT"

- create a view with the enums converted to int.

 

"database INSERT" does work without hacks: you can use clusters with enums to insert data into MySQL tables. The only caveat there is that LV enums start at zero, whereas MySQL enums start at 1. I work around this by adding an "undefined" value in the Labview enum.

 

My suggestion is to support enums in the database toolkit. After all, in Labview, it is not hard to convert a string into the matching enum.