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.

Listbox dividers are included in keyboard navigation of the listbox (arrow keys), without visual feedback. 

 

Dividers, which can't be selected programmatically or by mouse clicks, should be skipped during keyboard navigation.

 

See this post.

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

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.

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

 

1 (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 (annotated).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.

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

000.png

001.png

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

002.png

003.png

004.png

005.png

006.png

007.png

 

Feedback and questions welcome. 

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.

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

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

dwb_1-1729527929738.png

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

 

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.

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

 

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

 

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

 

When is LabVIEW going to get with the times?

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.

This topic keeps coming up randomly.  A LabVIEW class keeps a mutation history so that it can load older versions of the class.  But how often does this actually need to be done?  I have never needed it.  Many others I have talked with have never needed it.  But it often causes problems as projects and histories get large.  For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes.  The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.

 

My proposal is to add an option to the class properties to keep the mutation history.  It can be enabled by default to keep the current behavior.  But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

The LabVIEW Robotics Module consists of a variety of sensor and actuator drivers, motion algorithms (such as kinematics), world map creation and search algorithms, a world simulator, etc.

 

It hasn't been updated since 2019 and is 32-bit only.

 

I would like to see it made open source.

I believe some or all of the sensor drivers are already available on ni.com/idnet.

There are several other VI-based components and examples that are standalone and could be easily released independently.

I realize that the simulator might have some 3rd party constraints for releasing as open source, but I'd love to see it released if possible.

One thing I love with LabVIEW is to be able to execute the same source code on multiple targets (Win, Linux, NI Linux RT, etc)

 

I use Linux more and more to deploy my LabVIEW built apps and now instead of VM I use Windows Subsystem for Linux (WSL) on Windows 11, in very few steps I can create an Ubuntu instance, add a desktop and xrdp and then remote desktop into it.

 

What would be fantastic is to not event need a desktop and xrdp but just install LabVIEW in the WSL instance via terminal and then run LabVIEW on Windows and select the WSL instance as execution target as I would do for an RT target.

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.

 

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This idea is inspired by this idea and this idea.

 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. 

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Combined v2.png

 

 

 

 

 

 

 

Details

  • The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
  • The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
  • “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

  • .NET: System.DateTime.Now
  • C++: std::chrono::system_clock::now()
  • Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

 

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

 

Nevertheless, I would be happy with the following names too:

  • “Get Timestamp Now”
  • “Get Current Date/Time”
  • “Get Current Timestamp”

Notes

  • Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.