0

When entering a QState in QStateMachine a few Widget object properties are set with assignProperty() and the entered() Signal is used to run a Slot method that exec()s a QDialog.

This principally works, but the dialog is created before the properties are assigned, which is not desired, as the properties are only eventally assigned after the dialog is closed.

The exact order were not critical if the dialog would not block (what exactly does it "block"?). The human-perceived appearance should be "simultaneous".

A solution would make the dialog non-blocking or ensure the properties are set prior to the dialog's execution.

I will now try to use a single-shot QTimer to delay the slot that runs the QDialog's exec() but of course I am still looking for a proper solution even if this should work.

handle
  • 5,859
  • 3
  • 54
  • 82

1 Answers1

0

Currently, the idiomatic solution is to have two states: First one to set the properties, the second one to show the widget:

QStateMachine machine;
auto * s1 = QState(&machine);
auto * s2 = QState(&machine);
machine.setInitialState(s1);
s1->assignProperty(widget, "property", value);
...
s1->addTransition(s2);
connect(s2, SIGNAL(entered()), widget, SLOT(exec()));
//or
s2->assignProperty(widget, "visible", true);
machine.start();

Note that QDialog::exec() is a slot, so you don't need a custom slot just to exec() a dialog. Connect a slot to the dialog's accepted() or finished(int) signals to get the result.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313