Very strange: Front panel freezes in while loop and case structure sometimes

[billko]

---

@aputman wrote:

---

@billko wrote:

---

@aputman wrote:

Edit the event for Run and unlock the front panel.

---

99% of the time unlocking the front panel to make the front panel responsive means you're doing something wrong.  In this case, you just shouldn't have a loop inside the event structure.  Fix this the right way, as others have suggested, by not having a loop inside an event structure.  This is a very bad habit to develop.

---

I agree with everything you said here but the question was why the programs were not the same.  

---

I only mentioned this because it seemed like the OP was going to run with the ball and base his code on what you said.  I think I replied to the wrong post.  It should have been a response to the post that said he was going to implement your explanation.

Yikes.

[pji]

I appreciate all the comments.

In some cases, a while loop inside an event structure is actually a simple and effective structure. See the attached example. Using the inner loops is a straightforward, clear way to wait for user's response in a sequential manner under each sub-task, rather than requiring multiple event cases, multiple shift registers, or multiple states.

[aputman]

---

@pji wrote:

I appreciate all the comments.

In some cases, a while loop inside an event structure is actually a simple and effective structure. See the attached example. Using the inner loops is a straightforward, clear way to wait for user's response in a sequential manner under each sub-task, rather than requiring multiple event cases, multiple shift registers, or multiple states.

---

I disagree.  That is bad design.  This is exactly what a state machine is used for.  Each one of those frames in the sequence structure would be a state and each state would make a decision about the path that the program execution will take.  The event structure should not be used to run code, especially long running while loops, nor should it be used to hold execution until another UI action occurs.  The event structure is most useful to gather input from the user and send instructions to a different section of code that handles the processing of the event.  If you have ever pushed a UI button and the program didn't respond immediately when pressed, you would understand how it feels to have an unresponsive or slow reacting UI.  In your case and for the users of your app, that's the result of having running code inside the event structure.  

In this code, once a task is started, how would the user go about stopping the task prematurely?  What if this task was in control of a machine that unexpectedly went out of control.  How would you stop the task and shut down the machine?  You would need to physically pull the plug, or hit an ESTOP button (if available), or wait for the long running loop to finish execution, only after the user has repeatedly acknowledged the repeating dialog boxes.  

[Intaris]

I also disagree that is is bad design per se.  Yes, for given applications it can be a bad fix to an underlying problem but there are other applications where removing the FP Lock is perfectly OK.

I think the "bad design" was aimed at a specific use case where is can indeed be very indicative of bad design.  A disclaimer that this is not generally applicable would prevent it from becoming another "Globals are evil" statement.

[billko]

---

@Intaris wrote:

I also disagree that is is bad design per se.  Yes, for given applications it can be a bad fix to an underlying problem but there are other applications where removing the FP Lock is perfectly OK.

I think the "bad design" was aimed at a specific use case where is can indeed be very indicative of bad design.  A disclaimer that this is not generally applicable would prevent it from becoming another "Globals are evil" statement.

---

Are you accusing me of hyperbole?  Me?  No way!  Never in a zillion years!  😄