QState::entered behaviour
-
Hi,
I've got a question regarding the QState-class.
I have created my own class which is a child of the QState-class by inheritance because I want to fire some special events whenever a state is entered et cetera.In the constructor of the qstate-class I connect a lambda-function to the entered-signal:
connect(this, &QState::entered, this, [this](){ qInfo() << this->active(); }, Qt::DirectConnection);
I would expect it to always print true - however it is always false?
How am I supposed to interpret that?- The state is in the process of being entered, therefor not active yet?
- Am I messing it up by specifying Qt::DirectConnection? If I use Qt::QueuedConnection, it prints "true", as I would expect it..?
Thanks in advance,
Unzu -
@unzu I am not comfortable with
QState
(I never use it), but in documentation I can see a signalactiveChanged()
.
This tells me that entering a state does not obviously means the state is active.As side not, in your
connect()
sender and receiver are in same thread (they are the same also ;)) so the connection will be per default direct. -
@unzu said in QState::entered behaviour:
I can't figure it out :P
well there was some times ago, a little help, which I can find again.
There are "common" wiki escapes sequences like:- `keyword` ==>
keyword
- *cursive* ==> cursive
- **bold** ==> bold
- ***bold and cursive*** ==> bold and cursive
- `keyword` ==>
-
Hi,
Are you doing anything else beside connecting that lambda ? If so, you are using a canon to kill a fly.
There's rarely a need to subclass the QState class.
-
Pure curiosity, would you mind telling a bit more about the design of your subclass ?
Usually, you have objects that are "controlled" by the state like shown in the examples of the framework.
-
@SGaist said in QState::entered behaviour:
Pure curiosity, would you mind telling a bit more about the design of your subclass ?
Usually, you have objects that are "controlled" by the state like shown in the examples of the framework.
Hi, I completely forgot to check for responses because I marked the thread as finished, sorry.
I put some functions in the sub-classes which I want to react to events from 'outside', but only when the state is active.
Of course there is no need to put a class around them, however by doing so, I've got the code and functions bundled together where they belong to: the specific states. That gives me some kind of overview over the mess which I am creating.. \o/ -
Ok, I see.
I would rather have an "enabled" property or something like that on the "controller class" connected to the state so that the object can also be tested without the full state machine.