Leaderboard

Prize 1: Since we are all probably going to be eating way too much BBQ this week, Aledyne would like to donate 1 FitBit Zip Wireless Activity Tracker to the cause! Prize 2: One copy of the book "LabVIEW: A Developer's Guide to Real World Integration".

I didn't think they did, but I was pleasantly surprised when I looked this morning. Here is the same property for the Tree (saved in 2012), also only available in 2012 SP1 and later. tree_FocusItem.vi Edit: Turns out the "Focus Item" property of the TreeControl class is only available in LabVIEW 2013 and later. My previous statement that it was available in 2012 SP1 is incorrect.

https://www.ni.com/training/

Elimination of the case structure isn't that important. The encapsulation of the state-machine is the important bit which is what you have achieved but It is only the equivalent of "create Sub VI" on the case. From your description, you are still "driving" the machine with external, module specific messages which causes you to require the application state-machine (execution engine or sequencer) to know what module specific messages to send and in which order. That's a dependency that I don't like. So. Keep the class and keep the case structure and hard-code the "Message X" and "Message Y" in a couple of frames (probably multiple hard-coded messages in one frame) and we are back to the API. The execution engine only has to worry about application stuff and not what language the state-machines speaks (I just feel that if the messages are hard-coded, then there isn't any point to them). At that point, you can rationalise the interfaces to the modules (same messages) and swap entire modules in and out with the same execution engine (same as switching out the actor, I suppose) OR swap the execution engine with another. The end result of breaking message interdependence is is that you get swappable modules, swappable execution engines and swappable user interfaces and whole sections of a project become reusable (which is why I'd love to see the project manager cope with nested projects).

Funny. I could use every one of those arguments as reasons why I prefer message handlers inside states. (Perhaps with the exception of #2, 'cause I'm not sure what you mean.) Earlier AQ said he suspects most messages will behave the same in all states. Oddly, I don't find that to be the case at all. Usually each message is only recognized in 1 or 2 states. I suspect the difference has something to do with how I think about and create state machines. Noooooooo...... *cry* Say it ain't so, Greg. ("When a man is in despair, it means that he still believes in something.") State machines don't have the concept of state queues. In fact, you'll notice Alex's state enum isn't on a queue. Sub VIs are one way to deal with a multiple states handling the same message in the same way. Another way that works in some situations is to create a vi containing a message handling case structure for all your common messages and drop that in the default case of the message handling case structures of your states that have a few extra unique message handlers. If the message isn't one of the unique ones, the common handler will process it. Functionally doing that is the same as creating a MessageHandler class and subclassing it for each state. I've done that too, but there's not much advantage to using a single-method class for each state's message handler.