LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Find objects within areas of code

List recent files by project

View All (7)

View All (1)

View All (4)

Create DotNetContainer Reference

If creating a reference to a .Net control you will observe that is reference type of ActiveXContainer is created which is sometimes confusing at a first sight.

Please introduce a .NetContainer (at least cosmetically at block diagram) for a better overview. If you are doing so, you could change as well the color of the ActiveX container with respect to the .Net container on the block diagram. If you have to change the programming interface, it would be much easier to spot where you have to do so.

View All (2)

Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:

The Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>

Unhelpful context help.

Text ring would have the least impact on existing primatives: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-Type-Function-needs-another-return-for-an-empty-path/idc-p/2588549/highlight/true#M25086

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".

I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.

Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.

My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.

Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!

Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.

Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.

Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.

View All (3)

Make Sync.vim extendable

View All (9)

Provide a way to either temporarily (via key press) or permanently (via a LabVIEW option) disable the automatic creation / insertion of shift registers when adding a loop around some existing code. Much like the auto insert feedback node in cycles option.

This feature generally gets it right when dealing with references or error clusters, but other times it'll connect irrelevant data together, requiring extra effort to undo and rewire. The auto-wiring also creates weird bends when connecting the shift registers. When an unwanted shift register is then changed back to a tunnel, the bent wires remain in place.

A typical use case:

View All (4)

Currently, the "Tab" key is not individually mapped to an action for Block Diagram interactions; my suggestion is to use it to swap between "control", "indicator" and "constant", in the same way we already do with the options of the right-click menu "Change to Control/Indicator/Constant".

As an example, having selected a control on the BD, by just pressing "Tab" we would transform it into an indicator, a second press to a constant, and a third one would bring it back into being a control.

I understand this is a simple thing, but personally, I feel this ends up being one of the most repeated actions we end up taking as developers and I believe it would be intuitive to map it to a familiar key to many of us - tab.

Thanks all,

Cris

View All (2)

Invoke Node:ScaleFit/AutoScale Axis

Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.

Current Method: Property NodeProposed Idea: Invoke Node

View All (4)

DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing). Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up. An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open. Many dlls have similar pointers/handles that need to be properly closed. This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.

A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created. That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle. This VI would contain the code to cleanup/close the contained non-LabVIEW references. Could have other uses, such as debugging.

I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help. Please consider it.

View All (1)

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

View All (1)

Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.

I recommend the implementation of architectural warnings in the error log for detection of architectural mistakes. It would be nice if this could be toggled from the error log (like warnings) or had a viewer of some sort.

So far, I only have one architectural error that I’d like to catch, but I’m sure there are many others as well. Feel free to add suggestions for more architectural errors you'd like to catch.

Below I’m demonstrating the problems with bi-directional library dependence when using ppls. In this case the warning should state that: “Bi-directional dependence detected between Lib3 and Lib4”.

Initial state:
Lib4 initial state
and
Lib3 initial state
So we have bi-directional dependence which can only be seen through usage of multiple projects.
Lib3 built to Packed3 and replaces Lib3:
Lib 3 replaced with Packed3
Everything seems fine and the replace operation worked.
Now look at the project used to build Packed3:
Lib3 code locked
Lib3 depends on Lib4 but Lib4 has had a replace operation so it depends on Packed3 --> Packed3 will always be in memory --> it is no longer possible to rebuild Packed3.
Reverse replace not possible, so manual reverse is required to fix the code again.

Note:

The VI hierarchy does not help at all 😞

:No help from VI Hierarchy

View All (3)

LabVIEW Idea Exchange

Find objects within areas of code

List recent files by project

Create User Event function : Output indicator's name should be input control's name

Close Current FP/BD window when open SubVI

Create DotNetContainer Reference

Path Type Function - Return text ring or enum instead of plain I16

Upgrading Labview From Old to New Versions - Not Easy!

Better Support for SIMD/Vectorization Optimizations

Add output to type specialization structure that outputs the number or name of the subdiagram executed

Allow to add a name to the type specialization structure subdiagrams

Make Sync.vim extendable

Provide an option to disable auto-insert of shift registers

"Tab" keyboard shortcut: Swap between "Control", "Indicator" or "Constant"

String control/indicator/constant with code formatter

Invoke Node:ScaleFit/AutoScale Axis

Means to register a DVR-cleanup callback fior use when DVR released when VI goes idle.

Make text search look inside error ring constants

Standard marking for when 'error in' is ignored/passed through

Support Larger Glyphs in Listboxes and Trees

Add architectural warnings to the error log