QState::entered behaviour

unzu

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

KroMignon

@unzu I am not comfortable with QState (I never use it), but in documentation I can see a signal activeChanged().
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

Thanks for the response!
I decided to use the activeChanged()-Signal, works fine now.
Btw, how did you highlight the "QState" and "activeChanged()"???
I can't figure it out :P

KroMignon

@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

SGaist

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.

unzu

No, I'm subclassing because there is a lot more happening in my substates.
I've just reduced my question to the lambda expression to improve clearness on what my problem is.

Thanks
Unzu

SGaist

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.

unzu

@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/

SGaist

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.