How to tackle the dataflow problem when Value Change event always triggers after another GUI event

[zigbee1]

We know that Value change event always triggers after another GUI event. Eg, the user modifies string control, the user clicks on a boolean control. Then event boolean clicked is triggered before event string control value change.

Now suppose somehow the GUI event that must happen to subsequently trigger the Value change event can potentially affect the data that Value change event is supposed to work on. How can we tackle this problem ?

For example, in a mockup application that the grand purpose is to have user entered values in a textbox logged to a file (no missing information is accepted, and there is a boolean to determine how the information is logged).

There are 2 controls, boolean A when clicked (mouse down) will load random number in text box B. Text box B is designed with event structure VALUE change which saves whatever values user enters into text box B to a log file.

There are 3 problems when instead of clicking anywhere on the front panel after modifying text box B, the user ends up clicking on boolean control A.

1. Event mouse down on Boolean control A will execute first, modifying text box B content before the user entered values in B get saved.

2. The value of boolean A can potentially affect how textbox B is loggged.

3. The value of boolean A affects how the file is logged and this is indeterminate. Somehow when running this VI with no Highlighting, the textbox B Value change event executes -before- boolean A value is updated (F to T). When running this VI with Highlighting, the boolean A value is updated (F to T) (because we click on it) -before- textbox B value change event occurs. Why is it like this ?

Now the situation I made up seems non-sense, but I believe it resembles one way or another a problem that you might run into. How would you solve this problem elegantly ?

[altenbach]

• You can set the string control to "update while typing".
• Are you sure appending the log to itself is reasonable? Wouldn't it grow without bounds if the users keeps entering strings or pressing the ingore button?
• Why isn't the "constant" a diagram constant instead of a control. Is the user allowed to change it?
• To reset just write empty strings or a false to local variables of the controls (renit to defaults" seems a bit heavy handed).
• All you probably need is a single event case for "ignore:value change" and "String" value changed", no need for the local variable..
• Also add a stop button and an event for it.
• You don't need the timeout event.

[zigbee1]

actually this is a mockup application with no real purpose so please excuse the coding style, etc...

However, the event structure and how the GUI control reacts must keep the way it is to remain the problem. The Update when typing property of the string control is a good suggestion, but it is not applicable to say if String control is replaced by a text table.

[altenbach]

---

@zigbee1 wrote:

..., but it is not applicable to say if String control is replaced by a text table.

---

Now you are changing the specifiations on us...

[zigbee1]

I hope I were describing the problem well enough.. I actually have a solution that involves Mouse leave event and keyfocus property. This ensures actions with textbox B execute before other codes and event of other controls get in the way. However this is a micky mouse appropach imo.

I would like to listen from other experts on other solutions...

[mikeporter]

The only time that this will be a problem (BTW numerics do it too) is if the subsequent event depends on what you entered into the front panel control, but have not yet entered. The most common source of this problem with current versions of LabVIEW is having key navigation setup on a button.

The correct fix it to force the key focus property for the string (or numeric) to false before you read the control's value.

Losing key focus is what causes LabVIEW to copy the data from the screen buffer (what you see on the front panel) to the data buffer (what is seen by code reading the control on the block diagram).

Mike...