LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Andi_S

Mechanical Action for Knob, Dial and other numeric controls

I am currently struggling with the issue that the shown knob permanently triggers "Value change" event as long as the user has not finished adjusting it yet (left mouse button is still pressed). This may be an intended behavior, but it is not in my case.

For boolean elements, there is the configuration option of "Mechanical Action". For strings, there is the option "Update value while typing". However, there is currently no such option for numerical elements.


Therefore, I would like to suggest the following:
Add an option "Update while adjustment" - true by default, so it acts as it do currently. If this option is set to false, the "Value change" event would only be triggered after the input is completed by the user.

9 Comments
Christina_R
Active Participant

Unfortunately, I think having an option on sliders/knobs/dials where the value didn't actually change until the "mouse up" would encourage people to build UIs that didn't meet the expectations of operators. For example, the operator might be trying to "tune" something where they need to view the output and make fine adjustments. This is a lot harder if you have to click and click again (rather than click and hold).

 

It is inconvenient to have to discard some value change events, but it is possible to do so by writing code that checks the Time that the event fired and comparing it to the last time. 


Christina Rogers
Principal Product Owner, LabVIEW R&D
Andi_S
Member

Hello Christina,

I don't understand your objection. It is up to the programmer to create an appropriate user interface for his application.
My intention was not to change the current standard behavior of the knobs/.., but rather to add the described new option. The control should not change its visible behavior - the knob should naturally moves when the user grabs it with the mouse - but the value change event should only be fired when the mouse button is released.

 

By the way, ignoring events based on the timestamp doesn't help for two reasons:

a) You don't know which event is really the last one ... so you would have to construct something based the timeout event or any other timing functionality.

b) The mouse release event is not triggered if the mouse is moved out of the control while still pressed and then released.

 

If you want I can send you an example VI ... or you send me a VI that simulated the behavior as I'd like to see it.

Andi_S
Member
Let's take another look at the string control as well:

Here you offer the option "Update value while typing". In principle, this is not different to the current knob/slider behavior. It could be called "Update value while mouse moves".
With the default setting of a string control the "value change" event is only fired when the input is finished by leaving the control. This option to wait until the end of the input is simply missing with the knobs. It could be named as "Update value on mouse release". And please note that I'm exclusively concerned with the operation of the rotary knob / sliders and similar. It would make no difference for entering the value via the digital display.

fefepeto_kb
Member

If we take a short look on how .Net implemented in C# can solve the problem we realize that it is by far not trivial. Sine a leave event requires the user to "click" outside the control, practically to make another control in focus this type of event is not suitable for this scenario.

As Andi pointed out, mouse events don't work outside of the control, which is also true for .Net.

The only solution I can come up with is, that the container or the Form handles the event, so all the controls containing the knob would simply defer the event to their container, until the form handles it, potentially as a mouse up event. To make it work there has to be a mouse down event on the form too, that captures if the knob was pressed, and keep this until the mouse up event. But, this also means that the control update has to be solved as part of the mouse move event.

Great, this works for this control. Now, the issue is handling all the other controls. It might not be a big problem, since the control gets the event first, and for some events it can decide whether it lets the containers also handle it, but it can be tricky if more than one controls are inside the container. Then it has to be separated inside the container/form event. Not impossible, but certainly a lot of work.

With all this said, I think the only way to implement such a mechanism is to implement where it is used.

Christina_R
Active Participant

Can you please tell me more about the application where you want a knob to turn, giving the operator feedback that it is set to a specific value, and yet not put that new value on the wire that's connected to its terminal? (I know the original post is about value change events, but if the control isn't updating its value, then it would affect both coding scenarios.)


Christina Rogers
Principal Product Owner, LabVIEW R&D
Andi_S
Member

Yes, sure.

My application is the following:

An actuator (e.g. a lamp) shall be set to a specific value. The range is from 0 .. 100%.
So my UI contains a knob where the operator can choose the lamp value. The lamp is connected via an Interface (e.g. USB) the the PC. Sending a command and waiting for the answer (the lamp needs time to reach the value and stabilize) takes a while - let's say 3 sec. In this time I cannot / should not send new commands.

 

My idea was, that the operator can move the knob or slider to the wanted value and then release the mouse-button. Then the value change event should be fired and so I can send the new value to the hardware.

But currently there is a bunch of value change event fired all the time he moves the knob from the starting position to its final position. I cannot easily differentiate which of the events is the one that shall cause sending the command to the hardware.


Here is a picture of the example VI, it fired 125 events while moving the knob from 0 to 87.
Unfortunately I cannot upload videos or VIs here 😢

Andi_S_0-1724057956739.png

 

 

 

wiebe@CARYA
Knight of NI

This problem has been noted before with sliders:

 

Create a "User Control Ended" Event - NI Community

 

I'll leave it to NI to call it duplicate or not...

Andi_S
Member

@wiebe

Thanks for this hint. I agree, it solves the same problem with a different approach.

 

Christina_R
Active Participant
Status changed to: Duplicate

Create a "User Control Ended" Event - NI Community


Christina Rogers
Principal Product Owner, LabVIEW R&D