How can I keep running event-based state machine by a single event

[altenbach]

Did you even study my example? Your repeatable code belongs into the timeout event, not in the switch change event. Also, some of your events seem to output a timeout of zero (via "use default if unwired"), so other things could trigger a timeout and cause chaos.

If there are also many other event cases, you also need to ensure that your timeout code still gets a reasonable slice of the pie. How critical is timing?

[REDUANUL]

@  RTSLVU,

Your concept works after making some changes.

Thanks 🙂

@ altenbach,

Thanks to you for your effort 🙂 I think RTSLVU suggestion was easier to implement in my code.

[johntrich1971]

---

@REDUANUL wrote:

@  RTSLVU,

Your concept works after making some changes.

Thanks 🙂

@ altenbach,

Thanks to you for your effort 🙂 I think RTSLVU suggestion was easier to implement in my code.

---

Be careful. RTSLVU's suggestion is also easier to mess up. 

[altenbach]

---

@REDUANUL wrote:

I think RTSLVU suggestion was easier to implement in my code.

---

Mine solution is quite trivial once you understand it, and I guess you don't. 😉

Be aware that using signaling properties can be a mine field and you need to be very careful. It is typically a really bad ideas for events to trigger themselves. You must also know that signaling properties fire a "value change" event even if the old a new values are the same. (the description in RTSVLUs post and diagram comment are somewhat misleading). At least "measure?" is an indicator to prevent the user from adding to the event queue, but also preventing you from operating the button. I thought you needed that. Of course you could kludge your way around that by adding e.g. a "mouse down" event for it, but that just leads you even deeper into the swamp.

Feel free to attach your final solution so we can make sure it is implemented safely.

[RTSLVU]

---

@altenbach wrote:

---

@REDUANUL wrote:

I think RTSLVU suggestion was easier to implement in my code.

---

Mine solution is quite trivial once you understand it, and I guess you don't. 😉

Be aware that using signaling properties can be a mine field and you need to be very careful. It is typically a really bad ideas for events to trigger themselves. You must also know that signaling properties fire a "value change" event even if the old a new values are the same. (the description in RTSVLUs post and diagram comment are somewhat misleading). At least "measure?" is an indicator to prevent the user from adding to the event queue, but also preventing you from operating the button. I thought you needed that. Of course you could kludge your way around that by adding e.g. a "mouse down" event for it, but that just leads you even deeper into the swamp.

Feel free to attach your final solution so we can make sure it is implemented safely.

---

In my case there is no "measure button" for the end user to operate, in facts it's a hidden indicator. There is no user interaction except a Stop button that is handled in another Event Case. 

It probably would have been better to put this in the Time Out Case, (Where I initialize my instruments) and make an Initialize case that runs first.

But it was one of my first attempts at a EDSM and I just learned about putting initialization in the Time Out case and then setting the Timeout to -1 so it only runs once.

[johntrich1971]

---

@altenbach wrote:

---

@REDUANUL wrote:

I think RTSLVU suggestion was easier to implement in my code.

---

Mine solution is quite trivial once you understand it, and I guess you don't. 😉

---

Your solution is more trivial than RTSLVU's solution. I will admit that I've done things like RTSLVU's solution before, but also ran into some of the caveats. Your solution is much cleaner.

[mcduff]

Late to the party. But an architecture like the JKI State Machine would work here. Nothing in the event case, but a pointers to the next states, after those states execute decide if you need to execute them again. Keep the event structure neat and empty.

mcduff

[mcduff]

---

@RTSLVU wrote:

---

---

In my case there is no "measure button" for the end user to operate, in facts it's a hidden indicator. There is no user interaction except a Stop button that is handled in another Event Case. 

It probably would have been better to put this in the Time Out Case, (Where I initialize my instruments) and make an Initialize case that runs first.

But it was one of my first attempts at a EDSM and I just learned about putting initialization in the Time Out case and then setting the Timeout to -1 so it only runs once.

---

This is a case where a USER Event would be better. Since there "measure" control is hidden, it is unneeded, just trigger a User Event as needed. Once again, I suggest a proper State Machine architecture of your choice, keep your event cases mostly empty when possible. If you don't want to go that route then seriously check out and try to understand @altenbach's suggestion/solution. As usual, it is elegant, simple, and this time, the size of an address label.

mcduff

[RTSLVU]

---

@mcduff wrote:

---

@RTSLVU wrote:

---

---

In my case there is no "measure button" for the end user to operate, in facts it's a hidden indicator. There is no user interaction except a Stop button that is handled in another Event Case. 

It probably would have been better to put this in the Time Out Case, (Where I initialize my instruments) and make an Initialize case that runs first.

But it was one of my first attempts at a EDSM and I just learned about putting initialization in the Time Out case and then setting the Timeout to -1 so it only runs once.

---

This is a case where a USER Event would be better. Since there "measure" control is hidden, it is unneeded, just trigger a User Event as needed. Once again, I suggest a proper State Machine architecture of your choice, keep your event cases mostly empty when possible. If you don't want to go that route then seriously check out and try to understand @altenbach's suggestion/solution. As usual, it is elegant, simple, and this time, the size of an address label.

mcduff

---

Interesting, as I picked up using a hidden indicator and popery node to trigger an EDSM right here on this forum by one of the major players...

They even described it as a "Pro Tip".

[mcduff]

---

@RTSLVU wrote:

---

---

Interesting, as I picked up using a hidden indicator and popery node to trigger an EDSM right here on this forum by one of the major players...

They even described it as a "Pro Tip".

---

I am NOT a PRO, so take everything I write with a good dose of healthy skepticism. I have no idea why that method would be preferred over generating a User Event. Do you still have the link to that thread? One thing I don't like about that suggestion is the "property node" which signals the event; I believe that runs in the UI thread, whereas user events can be generated in any thread. (I normally use user events coupled to JKI State machines to have asynchronous communications between processes. Events allow: many to one, one to many, different message types to the same mailbox, etc, highly flexible. The same event structure can handle UI events, incoming messages from User events, etc)