LabVIEW Idea Exchange

Hello,

Today, ActivX and DotNet events are treated as callbacks ... ( A vi is linked to a callback )

It should be nice to handle them as LabVIEW events, so the callback treatments could appear in the LabVIEW event loop structure.

I think there is certainly a difference between events and call back handling, but it should be a way to standardize the "event/callback" view.

=> It would be more "user friendly" ... and applications could be more "maintenable" ...

Manu.net

I'm working on a high-performance application where every bit of time counts.

LabVIEW's parallel execution helps but we are having to write individual functions in C so we can try out the AVX instructions available on modern processors.

LabVIEW recently used SSE2 so I guess the compiler supports this (well, LLVM certainly does). It would be good to have an advanced option to enable more recent updates (AVX+) to avoid going to C!

I've been programming in LabVIEW for a decade.  Yet, there is still an issue with type def'ing a cluster.  If one of the goals of LabVIEW programming is documentation, why does NI still make it the process difficult?   

After creating then 'type def' a cluster, I then have to more spend time unhiding and repositioning labels. This gets extremely inefficient with large cluster.

Why not add an option to hide or leave labels untouched when 'type def'ing a cluster?

I need to detect when a user has released mouse control of a slider, but that is not possible. I would like to see a new event on controls called "User Control Ended".

For instance, consider a user grabbing a slider knob:

The user is able to drag the mouse anywhere, even outside the bounds of the window, and still have control of the slider:

And if the user Mouse Ups outside the window, you can't detect when that event happened. Here, Mouse Up and Mouse Leave are of no use on either the control or the pane. The new "User Control Ended" event needs to be robust like "Drag Ended", detecting events that happen even outside the VI pane.

Conclusion: when a user is interacting with controls using a drag-like operation, I need to know when the user releases the mouse button, whether it be inside the pane, outside, wherever. I have illustrated the example using a slider, but the idea I think should encompass nearly all controls (e.g., a user clicks on a Boolean with "Switch when Released" mechanical action, then drags the mouse outside the Boolean and releases to effectively cancel the Value Change event. Well, I'd still like to catch the "changed mind and released mouse button elsewhere event", a.k.a. the "User Control Ended" event)

EDIT: Attached the VI so you can play with it.

It would be nice if it was possible to restrict the autoscaling (in graphs and charts) to one direction only, and to limit its operation to a certain range.  A typical use for this would be to set the scale minimum to zero - and then let the autoscaling adjust the scale maximum.

You can of course achieve this by writing your own autoscaling function, however the need for such coding could easily be eliminated by adding a few options to the already existing feature. 

In addition to the directional limit and range it could have variables like a minimum step size / maximum allowable overshoot, maximum number of points off-scale etc.