View Full Version : Advise sought for QStateMachine implementation

9th February 2013, 18:02
I never used QStateMachine, but always wanted to try. I think that following example might be just the right application to try QStateMachine on.

There is an application that implements ten different actions. Each action is invoked from the main menu and execution takes variable time, from 1 minute to several hours. Each action has unique identifier (enum) and at the end of each execution the main window (where actions are implemented) emits commandIsCompleted(int actionid) signal.

I am in need to implement scheduling for these commands. Schedule should start at a given time and execute all ten commands sequentially, starting the new one when previous is completed.
I am thinking of creating an instance of QStateMachine and add the QState for each of the commands.

Upon startup statemachine subscribes to "commandIsCompleted" signal and posts the event with the action ID of the first command to the main window. On each signal statemachine should start the next state which in turn will post new event to the main window.

So, my pseudocode looks like this

enum actionId
actionOne =1,
QMainWindow* mw;
QStateMachine sm;
connect (mw, SIGNAL(commandIsCompleted(int)), &sm, SLOT(onCommand(int)));

QState* ps = nullptr;
for (int i = actionId::actionOne; i <= actionId::actionTen; ++i)
QState* a = new QState();
a->setProperty("actionid", i);
if (ps != nullptr)
ps->addTransition(??? to s);
ps = a;
That's where I stop: I don't understand how to organize transitions and also how to organize the sending of the event in each action..., or even if statemachine is appropriate at all.

I can easily implement the scheduling without statemachine, but want to understand if it can be applied to the above scenario.


9th February 2013, 18:19
I don't think this is a good usecase for QStateMachine. The most naive implementation of a solution to your problem is the following:

class Object : public QObject {
Object(QObject *parent = 0) : QObject(parent) { m_current = 0; }
public slots:
void start() { m_current = 0; execute(); }
private slots:
void execute() {
QString method;
switch(m_current) {
case 0: method = "stage0"; break;
case 1: method = "stage1"; break;
// ...
QMetaObject::invokeMethod(this, method, Qt::QueuedConnection);
void stage0() { ... emit stageComplete(m_current++); QMetaObject::invokeMethod(this, "execute", Qt::QueuedConnection); }
void stage10() { ... emit stageComplete(m_current); emit finished(); }
void stageComplete(int);
void finished();
int m_current; // or enum

Of course stageX() doesn't have to be a single function. The point is that at the end of its execution it adds to m_current and calls invokeMethod("execute"); (or invokeMethod("stageX+1") )

QStateMachine doesn't really offer you any benefits for such a linear flow.

12th February 2013, 16:50
Well, a state machine has the advantage of making the process very explicit.

The commandIsCompleted would trigger the transition into the next state and each state's entered signal would trigger running the respective task.

It is not necessary but can help to make the intent of the code more explicit.


12th February 2013, 17:33
Well, a state machine has the advantage of making the process very explicit.
Well... for a linear flow you can just connect signals and slots directly. I still fail to see a benefit of using QStateMachine here. QStateMachine can't even answer the question "what state am I in?" without writing additional code.

14th February 2013, 03:30
The benefit is not in the behavior but in documenting the workflow very explicitly.

Developer tools like Gammaray can then also easily introspect and display the state of the processing pipeline.