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

Question

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 ?
 

Answer 1

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.