Have a look at the State Machine Framework documentation here. Basically make one state with your defined transition, and create your other states accordingly with the parent state that has your single transition defined. Good luck.

Hi, The QtSCXML module being currently a technical preview, you should bring your questions to the interest mailing list. You'll find there QtSCXML's developers/maintainers. This forum is more user oriented and there's likely less people having already used that module here.

Hi and welcome to devnet, The QtSCXML module being currently a technical preview, you should bring your questions to the interest mailing list. You'll find there QtSCXML's developers/maintainers. This forum is more user oriented and there's likely less people having already used that module here.

Hi ankit thakar, have a look at http://doc.qt.io/qt-5/qstatemachine.html

@JohanSolo Thanks for the suggestion. I had done some reading about blockSignals() but I went back and looked again. The problem with blockSignals() is that it still leaves me needing to know that I wanted to emit a particular signal but couldn't. I somehow need to know how to re-emit the signal later when the server interaction completes. An event filter would almost work. I could add a filter for my QState objects. In that case what comes to the eventFilter() method is a QSignalEvent. If I could detect in the filter that my server operation was in progress, then I could save away the event (or the event parameters) then use them to post the event equivalent of the original signal at the correct time. I could dynamic cast the event pointer and even peel off the arguments, but there does not appear to be any public constructor for a QStateMachine::SignalEvent, so I have no way to reconstruct a copy of the original event. I also looked at using QAbstractTransition or QSignalTransition, but those basically have the same problem. There's no way to store the event to use later.

Hi, The only good answer is: benchmark. In any case, Qt's State Machine Framework is not know to be slow so unless you're expecting speed of light it should run well enough.

Yes that is correct. Every of the 8 custom gestures defines its own set of data in addition to the QGestureState, which is set by the according gesture recognizer. I now implemented an abstract superclass for all these gestures with a method getGestureData(). This method basically wraps all the data in a QMap<QString,QVariant> to make a general gesture treatment possible. The custom event GestureEvent now takes gesture type, the Qt::GestureState and the mentioned gesture data map. It was a little bit circumstantial, but now it works. Thanks again, Malte