LabVIEW Idea Exchange

This is not functional idea, but nevertheless - the point is that context help of boolean operation functions will contain not just text explanation of how does the function work, but also truth table. Thus it will be clearly seen all combinations of input values, and the resulting function output value - visualizing is always better than text description.

I have a simple idea that would help me tremendously when I open LabVIEW on an unfamiliar installation. Just add plain text descriptions on the installed compnents under the icons. By the way, some of these are explained wrong, on purpose, to prove a point 

As touch screens are becoming very popular and limitation of using keyboards in the production sites, the OSK is becoming very popular requirement and in LabVIEW applications.

Add OSK as an in-built property to String and Numeric controller. Based on control type open the numeric only or full keyboard.

The property can be set manually or programmatically.

Access to source code of OSK to customize the keyboard.

Multilingual keyboard option.

Thank you

Adarsh

CLA from 2014

Clusters allow you access to the decorations inside the cluster but you can also drop decorations on a custom .ctl file too but there is not way to programmatically access them.

The database toolkit is limted by the database variant to data function. It can only cast to a labview datatype as long as you wire that datatype to the type input. This means that you have to know the datatype of any SQL query in advance (or convert to string). It would be very useful if the function would also accept a variant datatype. This way it would be possible to cast any complex type into labview datatype, without the need of a predefined cluster.

Image - casting the database input with a the variant type input (circled) doesn't work

Problem - Bundle by name causes unnecessary wire bends because the type specifier is on the top.

Make the type specifier terminal on the upper left and the output on the upper right. Also right clicking on an item will allow you to select "Change to Read" or "Change to Write".

Would look something like the following.

Whenever I'm working on let's say a state machine I find that I need to resize the case structure now and then. Mostly make it larger, then I clean up my code and want to make it smaller again. Often when I do this, the constants (usually) pointing out the next case either get longer wires since they get further away from the border (when making the structure larger), become hidden (structure made smaller and no auto-grow) or prevent the resize (auto-grow enabled).

A solution to this would be to be able to lock BD objects with respect to the nearest corner of an owning structure, in the same way the loop index terminal is locked wrt to the corner of a for or while loop.

The idea of overloading methods is wide spread in other languages. Labview already supports this in a way with polymorphic vis.

The code snippet below has 2 classes, parent and child

methods are described in the image below. 

The underline idea is that parent can define 1 method (poly.vi) that can handle multiple inputs (polymorphic) but does not have to implement the functionality for all the input types (it just needs to know about them) and the child class can override poly.vi and the interface it want to implement.

Even though the code above is correct, Labview gives an error.

"Dynamic dispatch VIs cannot be members of polymorphic VIs."

I dont see why not, since dynamic distpacthing will still have an entry point for both classes (poly.vi) and choosing which polymorphic vi to use will be define at design time.