I'm trying to implement a state-machine in Qt (C++).
How can I check the current state of the QStateMachine?
I couldn't find a method in the documentation.
thx
have you tried QStateMachine::configuration() ?
refer http://www.qtcentre.org/threads/42085-How-to-get-the-current-state-of-QStateMachine
Excerpt from the above url:
// QStateMachine::configuration() gives you the current states.
while(stateMachine->configuration().contains(s2))
{
//do something
}
You can assign the property to the QStateMachine itself.
// QState m_State1;
// QState m_State2;
// QStateMachine m_Machine;
m_State1.assignProperty(m_Label, "visible", false);
m_State1.assignProperty(&m_Machine, "state", 1);
m_State2.assignProperty(m_Label, "visible", true);
m_State2.assignProperty(&m_Machine, "state", 2);
Then, the current state can be read from dynamic property.
qDebug() << m_Machine.property("state");
From Qt 5.7 Documentation
QSet QStateMachine::configuration() const
Returns the maximal consistent set of states (including parallel and final states) that this state machine is currently in. If a state s is in the configuration, it is always the case that the parent of s is also in c. Note, however, that the machine itself is not an explicit member of the configuration.
Example usage:
bool IsInState(QStateMachine& aMachine, QAbstractState* aState) const
{
if (aMachine_.configuration().contains(aState)) return true;
return false
}
I realize I'm coming in late, but hopefully this answer helps anyone else who stumbles across this.
You mentioned above that you already tried to use configuration(), but none of your states were there--this is because start() is asynchronous.
So, assuming you called configuration() immediately after calling start(), it makes sense that your states weren't there yet. You can get the functionality you want by using the started() signal of the QStateMachine class. Check it out:
stateMachine->setInitialState(someState);
stateMachine->start();
connect(stateMachine, SIGNAL(started()), this, SLOT(ReceiveStateMachineStarted()));
Then, for your ReceiveStateMachineStarted() slot, you could do something like this:
void MyClass::ReceiveStateMachineStarted() {
QSet<QAbstractState*> stateSet = stateMachine->configuration();
qDebug() << stateSet;
}
When your state machine enters its initial state, it will emit the start() signal. The slot you've written will hear that and print the config. For more on this, see the following Qt documentation:
http://doc.qt.io/qt-5/qstatemachine.html#started
Related
A google search gives these as the top three results:
Qt: Connect inside constructor - Will slot be invoked before object is initialized?
Qt can I connect signals/slots to self in constructor?
QT Connect Signal Slot and initialize in constructor
According to those, it seems like it ought to "just work" like anything else. But this code doesn't:
EditorList::EditorList(..., QWidget* parent) :
QWidget(parent)
{
...
Processing* processing = Processing::getInstance();
connect(this, SIGNAL(reorderDelete(DataSequence*,ListType,QList<int>)), processing, SLOT(reorderDelete(DataSequence*,ListType,QList<int>)));
...
buttonDelete = new QPushButton(this);
connect(buttonDelete, SIGNAL(clicked(bool)), this, SLOT(buttonDeleteClick()));
...
}
...
void EditorList::buttonDeleteClick()
{
...
QList<int> locations;
...
emit reorderDelete(mySequence, myListType, locations); //breakpoint 1 here
}
//-----------------------------------------------------------------
void Processing::reorderDelete(DataSequence* sequence, ListType listType, QList<int> locations)
{
if(sequence) //breakpoint 2 here
{
sequence->reorderDelete(listType, locations);
}
}
The reason for this structure, instead of calling mySequence->reorderDelete directly, is to have it done in Processing's thread instead of the UI's. I hope I haven't stripped out too much detail to show the problem; this is a rather large project.
When I click my delete button, I hit breakpoint 1 (so far, so good), but I don't hit breakpoint 2. My other signals/slots work across threads, but their connects are not in constructors. I want to make this one automatic so that every instance is "just connected" without having to remember to do it. Can I not do that?
Okay, I got it. Leaving up for others to find.
According to this, my ListType enum was blocking the system from making the connection. It only works with system-known datatypes because emitting a SIGNAL actually stores a copy for the SLOT(s) to read later. I knew that, but I thought it was more like a stack frame that could take anything. Apparently not.
It also works to put a call to qRegisterMetaType<ListType>("ListType"); somewhere before the connect. (I put it in my main window's constructor.) This makes the datatype known so that the connection can work anyway.
I'm hitting both breakpoints now.
Make sure you have used Q_OBJECT macros in your class
I'm coding a Qt Gui and I'm trying to implement a new feature, I now the precise result I want to arrive at but not how to code it.
I'm trying to add a checkable button that when checked would run a function that would only stop when the button is unchecked, but every second a PaintArea I have on the window would be updated (letting me see how the multiple executions of my function are changing my data). It seem that I'll need to use some QThread objects, but just the part dealing with the button is already counter intuitive to me, I've been trying to play with the autoRepeatDelay and autoRepeatInterval without getting my hand on what they do and how they could be useful to me.
I guess that what I'm trying to code is not really original, would have an idea of the steps to implement it, or an example of a code?
Edit:
According to the first answers (thank you for them by the way) my question may not be clear. Putting on the side the thread thing, I'd like to implement an infinite loop that only starts when a pressbutton goes to pressed position (it's a checkable button) and stops only when leaving it. The first version I tried to do (with a while(button->isChecked() loop) would completely freeze as the application would be running the loop, the gui would freeze and the button couldn't be turned off (hence the idea of running it in a separate thread). Voila! I hope it's a clearer formulation. Thank you in advance.
Here's a simple skeleton of something that might work. Without knowing your exact requirements, it may or may not be right for your problem. Hopefully it will give you a few hints that do actually help.
void Ui::buttonPressedSlot(bool checked){
if (checked){
Processor *processor = new Processor;
connect(this, SIGNAL(abortCalculations()), processor, SLOT(abort()), Qt::QueuedConnection);
connect(processor, SIGNAL(updateNeeded()), this, SLOT(updateGui()), Qt::QueuedConnection);
QThreadPool::globalInstance()->start(processor);
} else {
emit abortCalculations(); // this is a signal in your UI class
}
}
You can then use the following for your calculations.
class Processor : public QObject, public QRunnable{ // QObject must always be first in multiple inheritance
Q_OBJECT
public:
~Processor();
void run();
public slots:
void abort();
void doCalculations();
signals:
void updateNeeded(); // connect this to the GUI to tell it to refresh
private:
QScopedPointer<QEventLoop> loop;
};
Processor::~Processor(){
abort();
}
void Processor::run() {
loop.reset(new QEventLoop);
QTimer timer;
connect(&timer, SIGNAL(timeout()), this, SLOT(doCalculations()));
timer.setInterval(1000);
timer.start();
loop->exec();
}
void Processor::abort(){
if (!loop.isNull()){
loop->quit();
}
}
void Processor::doCalculations(){
// do whatever needs to be done
emit updateNeeded();
}
I don't know if I really understand what you want to do, but I will try to answer.
First, you want a Button that send a start & stop info to control a thread. You can use a checkbox to begin. This check box send a signal when its state changes. Connect this signal to a slot that perform start thread and stop according to the boolean sent.
Second, in you thread you need to launch the events loop. After, set a timer that call you repaint after every timeout.
Hope it helped.
PS: take care of execution context with you thread and Qt's objects.
I am building a program with a largely sequential flow but also some alternative paths. I thought that a state machine might be the simplest way of implementing this since Qt provides such a class: QStateMachine (also see API).
However, I seem to have quite a number of states (20+). Also, I have a number of different transition events (let's say buttons 1-10). So e.g. pressing button x would cause a transition of state 13 to 14.
Entering or leaving each state should be able to execute specific functions with parameters, and while each state emits such signals, it is not possible to pass parameters, so that it requires a potentially large number of paramter-less functions.
Reimplementing QAbstractState also seems tedious for this matter, unless it would have methods similar to assignProperty() which allows setting QObject properties on "state-entry".
Is QSignalMapper along with several Signal-Slot-Connections for each state's transition signals to handle multiple actions an appropriate approach?
If you're using C++11, you can connect directly to a lambda that then invokes your function with a specified parameter.
Otherwise, figure out what object is the sender() of your signal, and set a dynamic property on that object. That property can be queried in the slot, and passed on to the function as a parameter.
For example (within a class):
void setup() {
QState *s2 = new QState();
s2->assignProperty(myLabel, "text", "state two");
s2->setProperty("prop", 0);
connect(s2, SIGNAL(entered()), io, SLOT(testSlot()));
}
Q_SLOT void testSlot() {
QObject *obj = this->sender();
QVariant prop = obj->property("prop");
qDebug() << __FUNCTION__ << prop.toString();
}
In my Qt Application I am dynamically creating 'Questions' in QVBoxLayouts for a 'Questionnaire'. There are 3 types of Questions: Boolean, Text, & Radio.
When the user 'adds a question' to the questionnaire, they are presented with a QComboBox. When the index/text of this QComboBox is edited, I want to act upon the SIGNAL emitted.
I would like to have something like Java's (from an old Android Project):
button.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
//Code to run...
}
});
Is it possible to have the same in Qt/C++ like:
connect(qvectorOfComboBoxes.at(qvectorOfComboBoxes.end()), SIGNAL(currentTextChanged(QString)),
this, SLOT(
void comboBoxTextChanged(QString newComboxBoxText)
{
//This doesn't work
} )) ;
I understand from another post on here the ideal approach is a QSignalMapper, but was hoping to perform the task in a manner similar to above.
Usually, I find my answers either on here or from a related Google search (I am probably searching the wrong thing as I don't know the name for this), and so was hoping somebody here could give me a yay or nay. Thanks
In Qt5 and using a C++11-enabled compiler, you can use lambdas as slots, as explained here:
connect(sender, SIGNAL(signal(QString)), [](QString newComboxBoxText) {
// add your code here
});
Otherwise, you can use sender() to query the QObject* which sent the signal, if this is enough information you need. To cast it to a QComboBox* please use qobject_cast<QComboBox*> and Q_ASSERT that it's not null. (You can't get a compile-time error that it was connected to some other type.)
I have two instances of QObject subclasses and two QMetaMethod instances of signal in one of objects and slot in another object. I want to connect this signal and slot with each other.
I've looked through the qobject.h file and find that SIGNAL() and SLOT() macro are just add "1" or "2" character to the beginning of method signature so it looks like it should be possible to add the same character to the beginning of string returned by QMetaMethod::signature() but this approach depends on some undocumented internals of toolkit and may be broken at any time by a new version of Qt.
Does anybody know reliable way to connect signals and slots through their QMetaMethod reflection representation?
Edited:
I've created suggestion in Qt issue tracker:
https://bugreports.qt.io/browse/QTBUG-10637
If anybody also interested in this feature you can vote for this ticket there.
This has been fixed as of Qt 4.8.0:
https://bugreports.qt.io/browse/QTBUG-10637
Suppose we have a QObject* m_subject, and wish to connect the change-notification signal of a property to a propertyChanged() slot:
const QMetaObject* meta = m_subject->metaObject();
QMetaProperty prop = meta->property(meta->indexOfProperty("myProperty"));
if (prop.hasNotifySignal()) {
QMetaMethod signal = prop.notifySignal();
QMetaMethod updateSlot = metaObject()->method(
metaObject()->indexOfSlot("propertyChanged()"));
connect(m_subject, signal, this, updateSlot);
}
I successfully used this to make a QWidget subclass which finds all the properties of any QObject and creates a QLineEdit for each of them, with a connection to keep the QLineEdit updated whenever the corresponding property changes. (Because I didn't find a way to pass a propertyID value to propertyChanged() though, it was necessary to make a subclass of QLineEdit and implement propertyChanged() there. QSignalMapper didn't help, because all the properties are in the same object.)
Thanks to MBack, I now use metamethods to connect my view to my model's properties dynamically for MVVM or MVC pattern.
In order to respect DRY, a boilerplate is required with something like this :
void MyClass::connectSignalToSlot(QObject* sender, std::string signalName, QObject* receiver, std::string slotName)
{
int sigIdx = sender->metaObject()->indexOfSignal(signalName.c_str());
auto signal = sender->metaObject()->method(sigIdx);
int slotIdx = receiver->metaObject()->indexOfSlot(slotName.c_str());
auto slot = receiver->metaObject()->method(slotIdx);
connect(sender,signal,receiver,slot);
}
void MyClass::connectPropertyChangedToSlot(QObject* sender, std::string propName, QObject* receiver, std::string slotName)
{
int sigIdx = sender->metaObject()->indexOfProperty(propName.c_str());
auto signal = sender->metaObject()->property(sigIdx ).notifySignal();
int slotIdx = receiver->metaObject()->indexOfSlot(slotName.c_str());
auto slot = receiver->metaObject()->method(slotIdx);
return connect(sender, signal, receiver, slot);
}
It looks like there is no way to make it work without relying on internal implementation. If I were you, I'd submit feature request to Qt bug tracker, write a code that mimics current behavior SIGNAL/SLOT macros and add unit test that will fail when SIGNAL/SLOT behavior changes.
There might be a simpler solution to the problem you're trying to solve: describe what exactly are you trying to do without any implementation details.
If signature method is public in QMetaMethod then the result shouldn't be broken by trolls and it's safe to use it (documentation says nothing about "dangers" when using QMetaMethod::signature method). I think you can safely use it. Just to be sure, what version of Qt you are using right now ?