Hello to all.
Solved! Go to Solution.
this is a good task for a state machine. I sketched a skeleton for a state machine that could lead you to a solution. The simple idea is to switch to the next state when the "Next" button is pressed and to switch to the previous state when the "Cancel" button is pressed. Every buttonpress then calls the event to show the controls according to the current state via the "Show new State" button (which only has to catch the event)
Your code makes little sense. Having an event structure with a 1ms timeout, containing a 100ms timeout seems a little weird.
If only one of the strings should show, maybe all you need is a single one where you change the text based on state.
Why are they controls if you use them as indicators? Is the user supposed to change the displayed text? (that would need very few adjustments to implement)
Maybe all you need is the following:
@Ngouda wrote:For the 100ms timeout, I have other tasks in my state machine that will run, I just sent this simple template(removing the other elements).I have several buttons that will appear because the user will have to choose his answer and I have to save his answer in a file and calculate the averages.I have several parameters that will indeed be displayed on the screen
Sorry, I have absolutely no idea what any of this means. What are "parameters" (controls? Indicators? Strings? Booleans?, etc.) and how does the user interact? Calculating averages can be done in memory, files are for logging.
Even for buttons, you can re-use the same buttons and just change the "boolean text" as a function of state, right? No need to juggle tons of buttons! Keep it simple!
Hello @knightThanks for your feedback.For the 100ms timeout, I have other tasks in my state machine that will run, I just sent this simple template(removing the other elements).
to clarify the problem Christian Altenbach mentioned, I want to explain what your code does:
If you wire a constant other than -1 to the events structures TimeOut Terminal, this means the event structure will wait after finishing execution of the last event for the amount of time wired to the terminal. In your case 1 ms. If an event occurs in between this span of time (e.g. a button click), LabVIEW will immediately abort waiting and start executing the appropriate event. If an event occurs while executing an event frame, the wait time is skipped and the next event is executed immediately after the last event.
If no event occurs, the Timeout event is executed.
If there is a wait node in the Timeout event (as in your case, 100 ms), an occurring event in between these 100 ms has to wait for elapsing this time. This could be 99.99 ms or 0.01 ms. You might say this is no problem, the user doesn't notice this little time. But it is bad practice and will cause issues if a device would be waiting for response.
So, wiring a 100 ms constant to the TimeOut terminal and having no wait node in the TimeOut event would mean: every event, like a button click, will be executed immediately and the code in the TimeOut event frame will be executed 100 ms after the last event (including the last TimeOut event).
Edit: some typos and little ambiguities.
Yes, you are exactly right.
I agree, but sometimes you get stuck and don't know how to ask the right question.
Since you are new to LabVIEW, I recommend taking yourself a whole day and have a look at the "Find Examples" browser. You can find it in the Help menu.
There it could be very interesting for you (as a newbe) to look at the examples in the branch "Building User Interfaces" and there "Controlling Front Panels Programmatically", "Customizing Controls" (not the XControl- Example), "General" and "Displaying Data/General".
Try to understand the code and principles and I think this will give you a lot of ideas how to achieve your goals effectively.