Using more than one event structure for the same control within a standard state machine

[sebster]

Voted "worst idea ever"?? Blimey!!! that's a little harsh. I don't know whether to be proud of this acheivement or to cry!!

I only came here for help. If I wanted abuse, I would have stayed at home.

Don't forget, we were all learners at one time.

Anyway what was so bad about my solution to deserve such a comment? It was a) simple to implement, b) invisible to the operator, and c) it worked and did what it was supposed to.

Nathand

That is exactly what I need, and using this structure in my test sequence works the way it should. UNTIL... I try to exit. What stops the top loop? What is in the 'other' event? Because that continues to run when the bottom loop closes.

Regards,

Sebster

[Ray.R]

---

sebster wrote:

Voted "worst idea ever"?? Blimey!!! that's a little harsh. I don't know whether to be proud of this acheivement or to cry!!

---

That statement was made because of experience...  Either from self or most likely from fixing someone else's implementation.

I tell my clients that they should avoid hiding controls at all cost.  I did get a customer who insisted on having a sophisticated Operator Interface which included two controls that would be swapped based on some criteria.  Implementing the code so that under NO circumstance the program would get stuck because the control was not visible was a lot more work than they could have imagined.... 

Hiding a control and making others visible is very simple indeed.  But to make 100% sure that all the controls that are needed are there and available when they are needed is a bit more tricky.

"worse idea ever"???  Well....  with experience, you learn that it is unfortunately true...  😞  It's a reality statement, not something meant to offend you  LOL! 😄

Dealing with two superimposed controls is one thing.  To deal with more that two superimposed controls that are made visible or invisible and inactive, and to do it well, will be a challenge..  Not because it is simple or hard...  but to cover all the possible angles that the right control will be the one that is visible and active and that no deadlock condition occurs.  Although that is the type of code that keeps us consultants wealthy 😉

R

[nathand · Accepted solution]

Since I put it together quickly I just added another "Stop" boolean to the front panel, and the other event case handled it.  I assume in a real application you'd want it to process events continuously until the user stops the program either by clicking a stop button, closing the window, or choosing Quit from a menu.  It's quite possible that for your program there's no need for an event structure at all and we've all helped make it too complicated.

That said, here's a version that exits exactly the way your original did, by generating a user event in the Stop case.  It seems like overkill for this simple application but demontrates how you could do it.  Note that I've changed the mechanical action for the Continue button to "Latch when released" which seems more approriate here.  You could also use a queue in place of a notifier, which would push this in the direction of a queued state machine, a very common framework.

[sebster]

OK, OK, point taken about my 'invisible' buttons. Any thoughts of using them are now banished from my feeble brain, never to return. But I am still learning, and don't have that experience of you guys. So there's no need to ridicule my efforts

And although I haven't implemented the closing of the 'top' loop yet (the one with the event structure in), it does look like I can go ahead and modify it to suit. And of course re-use it in future projects.

So I'm a bit more comfortable with the event structure now.

Lessons learned, and thanks to all for your inputs.  

Regards,

Sebster. 

[altenbach]

Sorry about the "valspeak" comment. It was, like totally, how I felt reading your idea. What-ever! 😄

You are still approaching all this way too complicated. If you think you need to throw that much code at it, just to get some simple UI mechanics, imagine how your code will look like once you add a little more meat to the program. 😉

It really would help to take a few steps back and look at the problem with an open mind.

As I demonstrated in my earlier example, all you need is a single while loop that can do all the looping for all subcode fragments. Place the case structure inside the loop instead of near identical loops inside each of the cases of the case structure and things will get orders of magnitude more manageable. You need to reverse your thinking! For real!

Tubular! 😄

[sebster]

Just an update of my progress with this.

I implemented the notifiers and the program kind of worked ...... but not really.

As I said in my original post, the while-loops are there to update a scaled graph which simulates an oscilloscope display. The problem I have is the graph needs to be updated with a delay of less than 20mS to maintain a stabalised waveform. Anything longer gave a lot of 'flickering'. (It's not a 'simple' waveform such as a sine wave, but more of a tone burst which is triggered from another channel)

With such a relatively short repeat rate, sometimes it 'missed' the notification to stop the loop, and it took several tries of clicking the button to catch it.

So I changed to using queues instead of notifiers (as suggested by nathand) and using a 'flush queue' after each while-loop stops, to prevent problems with double clicks filling the queue ready for the next while-loop.

The program now works perfectly even if I run the loops with only a 1mS delay!!

So now I know about:

a) event structures

b) notifiers

c) queues

d) the wrong way to do things is making controls invisible!!!

So thanks again for the help. I couldn't have done it without you.

Regards,

Sebster