LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Numeric Control Indicator - entered value not registered if trigger event by mouse on a different button

Solved!
Go to solution

I have a 3 number control indicators specifying X Y and Z, I enter each sequentially and tab between them. When I enter Z, I do not tab or enter, but I move the mouse over the enter key, and press. An event is generated for the button press, and the data from the control indicators is added to a file.

 

Unfortunately, the Z value is never registered, as it saves the value that was there before the current change. If I were to press enter twice, then the correct value is entered into the file.

 

Is there any way to force the control to register the value anytime focus from the field is lost. I tried generating an event to do that, but I do not know how to force the fields to register their currently displayed values (need to do this to all three fields, as the editing may not be in sequence)

 

Thanks for any help

0 Kudos
Message 1 of 11
(3,064 Views)

I tried a simple reproduction and it works fine for me. Can you post a minimum working example?

0 Kudos
Message 2 of 11
(3,050 Views)

My best guess is that the control terminal is located before (outside) the event structure, so it gets read before the event fires and you are getting a stale value from the tunnel. Typically, controls belong into their respective event cases.

 

(If that's not it, we need to see your code. We cannot debug ambiguous paragraphs.)

0 Kudos
Message 3 of 11
(3,010 Views)

I've been there, it's a nasty problem.

 

EDIT: Can't reproduce it in a simple example, but definitely seen this before. I'll keep typing.

 

You're typing in a control, and trigger a value change that stops the loop. The value change of the control is triggered after the button's event.

 

Pressing the button triggers the button value change event, and stops the loop around the event structure. The control that was being edited, doesn't get a change to send it's value change event to the event structure, it stopped:

 

User types value in Control.

User presses stop.

Stop value change event is triggered.

Loop is stopped.

Control value change event is triggered.

 

A solution is to re-route the stop buttons action. So, make a dummy stop button, that stops the loop. Trigger a value change:

 

User types value in Control.

User presses stop.

Stop value change event is triggered.

Stop value change event sends dummy stop value change event

Control value change event is triggered.

Dummy stop value change event is triggered.

Loop is stopped.

 

Another way is to use the event time out event: The stop event sets a stop Boolean in a shift register:

 

Time out event (stop == false)

Time out event (stop == false)

User types value in Control.

Time out event (stop == false)

User presses stop.

Stop value change event sets stop to true.

Control value change event is triggered.

Time out event (stop == true)

Loop is stopped.

 

Hope it helps.

0 Kudos
Message 4 of 11
(2,997 Views)

Attached is a demonstration.


In this VI, the loop is stopped at a Boolean button key down. As OP described in the question.

 

Instructions: start typing the string, press the button. Note the string value change event is not triggered.

 

The solution is simple for this VI: don't stop at a mouse down, use the value change event of the Boolean.

 

I have real life situations though where I get the same effect, not using a mouse down event. Using the mouse down even is simply not the right choice. Set Boolean mechanical action to switch when pressed to get this effect, although it's considered to give a bad UX (switch when released is normal).

 

Other events are triggered before the string value change event is triggered. Re-routing the stop action is a solution, either through a 2nd control, or through the time out.

0 Kudos
Message 5 of 11
(2,994 Views)

My scenario is a bit more complicated:

 

I have an item control (a ring or listbox) selecting an item.

I have value controls showing values of the item.

If the item ring changes, I update the value controls.

If the user is editing a value control (but doesn't apply the value), then changes the item ring, the values event are not always applied.

 

This gives a really nasty UX. The change of the item ring should work as an commitment of the changed value, but the changed value simply disappears. It's not always transparent, because when testing you might click next to a control or press enter to commit the change. It's easy not to notice during testing.

0 Kudos
Message 6 of 11
(2,990 Views)
Solution
Accepted by topic author RS7

I am not seeing that the OP uses a "mouse down" event instead of a value change, so I doubt your scenario applies here (but of course the description was vague enough that it could be ... ;))

 

Your scenario required quite a few poor choices and can be solved by setting the string to "update while typing" or setting the button event to "value changed". Or simply have the VI NOT stop on the mouse down event, so the string value change has a chance to fire immediately after. Even better, instead of using an "enter" button, I would set the string to "limit to single line", which will complete the string by pressing the enter key with no need to mouse off it.

 

In general, "mouse down" events are significantly more dangerous than "value changed", because they fire even if the control is disabled or even if its' an indicator. Somewhat of a loose cannon, IMHO. 😉

0 Kudos
Message 7 of 11
(2,968 Views)

For string controls, you can simply turn on "Update While Typing".  Unfortunately there is no equivalent property for other controls.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 8 of 11
(2,967 Views)

@paul_cardinale wrote:

 Unfortunately there is no equivalent property for other controls.


Probably a good thing. Imagine needing a microvolt and while entering 1e-6, getting 1V instantly while entering the first few characters. 😄

0 Kudos
Message 9 of 11
(2,963 Views)

@altenbach wrote:

I am not seeing that the OP uses a "mouse down" event instead of a value change, so I doubt your scenario applies here (but of course the description was vague enough that it could be ... ;))


He uses a "button press", which might translate to mouse down... Vague indeed.

0 Kudos
Message 10 of 11
(2,959 Views)