Value Not Updating When Mouse Leaves

[xkenneth86]

Hi All, I have a weird bug in my code where I enter data into a string control, and then move the mouse over to another button and hit it, but the value is not updated in that control when the button is hit, which executes some code that tries to read the value of that string control.

I put a value change event and I can see that the value change event is not happening until I click out of that control, but not hit the button, which fires another user event.

Any thoughts here on what may be causing this? Seems weird.

[Kyle97330]

I mean, it's pretty hard to debug this if you don't post code showing the problem.

However, since it's a string control, would it be acceptable if you right-click it and choose the "update value while typing" option?  That way the string value change should register every time a key press happens instead of when you leave the string control when you want to press the button.

[aputman · Accepted solution]

It sounds like the button event is firing first, before the text control is actually updated with the new value, meaning the button event is working with old data.  Changing the string control to "Update value while typing" is the simplest way to address that. 

[xkenneth86]

Thanks! That's what I did and it certainly helps!

Is there a middle ground way to have it update when you mouse leaves the control?

[xkenneth86]

Kyle,

Yeah I appreciate that, but sorry this code is super proprietary.

[aputman]

I guess I don't understand why the mouse has anything to do with this.  The string control has keyboard focus when you are typing, not mouse focus.  If you want to force the user to make sure the mouse icon stays on the string control while they are typing, and then update the string control when the mouse leaves that control, that would not be good programming practice and doesn't fit with standard UI functionality. 

Why is "update value while typing" not considered middle ground?  What is it about that solution that you do you not like?  

[xkenneth86]

I suppose you have a good point there, I am just thinking about the context of a GUI app where you navigate the mouse to the control, type and then navigate the mouse away.

I supose what bothers me is the extra event that's unnecessarily firing for *every* key I type. Perhaps a better middleground would be *fire the event if you haven't received a keystroke in "x" milliseconds.

[aputman]

What mechanical action do you have on your button?  Most often, it should probably be set to Latch When Released with the button terminal located within the button event.  

Maybe this is behavior that was fixed in newer versions of LabVIEW.  What version are you using?  There was a post on the Idea Exchange that was similar in nature.  This similar (but not exact) behavior was fixed in 2014. 

Having said all of this, using a simple example, I am unable to duplicate what you are seeing.  The string update event always occurs before the button event.  Maybe there is something in your code that is causing delays, which makes the button event run first.  Without seeing your code, unfortunately there is nothing else I can suggest.  

[Kyle97330]

---

@xkenneth86 wrote:

Kyle,

Yeah I appreciate that, but sorry this code is super proprietary.

---

The typical solution in a situation like this is to create a new VI which showcases the problem but without all of the surrounding proprietary stuff.  Sometimes from scratch, other times by making a copy of the offending VI and then deleting nearly everything except the problem area.

(As a fun bonus, often times making the trimmed VI often shows that the problem doesn't exist in slim code, and may point to the fact that the problem lies else where in your setup and not in the specific code you thought had issues...)

If that isn't realistic for whatever reason, a secondary approach is to just take a screenshot, and trim it and redact it to the point where only the most generic code appears.  But since active debugging on a PNG isn't a thing, it's not nearly as good.... but it's also still way better than nothing.