LabVIEW Idea Exchange

The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.

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.

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.

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

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.

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.

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.