Queued State Machine, not a state machine?

Question

I've been reading up a bit on design patterns that seem popular among LabVIEW users, and I have a question with regards to the design pattern described in the following article:
http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/
I don't see how this is a state machine at all. To me it just looks like a producer/consumer pattern for queuing up actions (what is described in the article as states) to be executed in the consumer loop. I don't see where a state machine comes into play, determining state transitions based on current state and inputs, like shown in the following:
http://zone.ni.com/devzone/cda/tut/p/id/3024
Am I completely off?

Answer 1

Yeah exactly.
I was thinking a nice way to implement something QSM-like would be to produce instances of a message handler object that maintains its own state and a message queue. You could produce a new object for network I/O that inherits from the general message handler, one for managing the UI, data aquisition etc. They would communicate in a network by passing messages back and forth to their respective queues and each would be a true implementation of a state machine.
Has to be right up LabVIEW's visual alley
Edit:
Now that I come to think of it, this would be almost exactly what could be done compactly with LabVIEW event handlers and user-generated events.