LabVIEW Idea Exchange

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

The return key should register a value change event on the active and edited control, before toggling any associated button.

Status: Declined
Moved to CAR database as CAR 447743

Scenario:

 

A user has updated the value of a control in a window that has an OK button that will close the window. The controls are in a loop with an even structure. The OK button is set to toggle if the Return-key is pressed, and its change event will stop the loop. The user is happy with the state of every input in the window, including the just entered change, and hits the Return-key to OK the changes. The window closes...and the user later discovers that the last input he made, just prior to hitting the return key, never got registered...Smiley Frustrated

 

The problem is that the Return-key does not trigger a change event for the active control *prior* to toggling the state of the OK-button. So if the OK button happens to stop the execution of the given VI, the last known value of the control that was active prior to the pressing of the return-key is not what the user saw at the time. People who use LabVIEW a lot get so used to this behaviour that they more or less unconciously click somewhere in the window with the mouse, or navigate elsewhere with the tab key to trigger an update, before they hit the return key. Everyone else get cought off guard.

 

Yes, it is possible to program around this problem by making sure that the toggling of the OK button does not stop the loop immediately but allows it to spin one more cycle just to make LabVIEW register the last control entry (or in the case of string controls, by setting it to "update while typing"). Adding such logic should not be necessary in this case though, it should be part of the in-built behaviour.

 

 

 

PS. Every time I run into this issue I feel like I must have overlooked or forgotten something. It cannot be true that this is not already handled automatically(!). I believe this problem was present even without the use of an event structure in some older versions of LabVIEW, or am I just getting senile?Smiley Wink

14 Comments
Mads
Active Participant

The bug fix list you refer to does not list CAR 447743 as fixed...Is the list incomplete?

crossrulz
Knight of NI

The list is far from complete.  That list is just the ones somebody inside of NI said was worth mentioning for who knows what reasons.  But Jeff-P is almsot always on the ball when it comes to following CARs for us.  If he says this CAR is closed, I would believe him.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Darren
Proven Zealot

I just double-checked...CAR 447743 is fixed in LabVIEW 2014.

Jeff-P
NI Employee (retired)

I would believe Darren more than me Smiley Very Happy

 

As Darren said, CAR 447743  was fixed in  LabVIEW 2014.  For a list of major bugs fixed in LabVIEW 2014, check the LabVIEW 2014 Bug Fixes. You can download an evaluation copy of LabVIEW 2014 at www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

 

To be clear, the bug fix list is not a complete list of all the CARs that are fixed. We try to include all CARs that an end user can encounter, and everything that we can give a reasonable description of. There are a number of CARs fixed for internal issues that would not make sense to put on the list. In this case it looks like the CAR was fixed very late in the release cycle (after we evaluated which CARs were going on the bug fix list) so it missed the cut. 

 

Regards,

 

Jeff Peacock 

 

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect