Issue with State Pattern Extension in Actor Framework

[GMParker]

 Hello everyone,

I'm not totally sure if this is the right place to post this, but I've run into an issue when trying to apply the state pattern actor from the NI State Pattern Actor package. I'm currently running LabVIEW 2025 Q1 and the most up to date version of the package.

It seemed straight forward enough to apply from the documentation provided in the example project, but it seems I'm having trouble transitioning between states. I've setup my own "context actor" named Test States and its corresponding children (idle, running) with their necessary overrides. It looks like this mirrors the behavior of their Process States context actor as well for state transitions. I'm able to execute the change state method, but that new state is not maintained by my launched state actor. This leaves me in the idle state. On the other hand, if I use the default implementation in Process States, it transitions fine and maintains that state until told otherwise.

Is there some simple detail I'm missing here? It's worth noting I'm still new to AF. 

I've attached the project below and set it up so that you can easily switch between my Test States context actor, and the original Process States in the State Pattern UI. Currently, my basic implementation is the default behavior. By the way, you can largely ignore the process actor. I'm just trying to change between states for now.

Thank you for any help you guys can provide!

[Quiztus2 · Accepted solution]

I can't look in your code but check your messages Do vis for 'Dummy Method' . There was a bug in state pattern a few years ago. Maybe wasn't fixed yet. State pattern is not much used I think, since you can lose yourself easily within the project tree having too many classes(states) in it

[avogadro5]

---

@Quiztus2 wrote:

I can't look in your code but check your messages Do vis for 'Dummy Method' . There was a bug in state pattern a few years ago. Maybe wasn't fixed yet. State pattern is not much used I think, since you can lose yourself easily within the project tree having too many classes(states) in it

---

Yeah the go to running msg has the new state unwired.

I worked with an OO state machine in the past and found it worked well, but it used composition so the state class was in the actor rather than being the actor class. Might be easier to test and conceptualize, changing actor class kinda freaks me out...

[GMParker]

---

@Quiztus2 wrote:

I can't look in your code but check your messages Do vis for 'Dummy Method' . There was a bug in state pattern a few years ago. Maybe wasn't fixed yet. State pattern is not much used I think, since you can lose yourself easily within the project tree having too many classes(states) in it

---

This was exactly the issue!

As a side note, is there something else you might suggest instead of state pattern that fulfills the same purpose? As I mentioned, I'm still very new, so any advice/resources for alternatives are greatly appreciated.

[Quiztus2]

First of all, stay away from LVOOP if there is no strong need for inheritance. Regarding state pattern: In order not to get lost in your project tree it is recommended not to have more than 2-3 states. E.g. Running, Idle, maybe Error. So one could argue that a simple boolean (running) and a case structure could be the more convenient solution than a hard to manage a class based state machine.