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 ?
Related
I have a QAction which I've assigned multiple shortcuts to it
test = new QAction();
this->addAction(test);
QList<QKeySequence> shortcuts;
shortcuts << QKeySequence(Qt::Key_N) << QKeySequence(Qt::Key_T);
test->setShortcuts(shortcuts);
connect(test,SIGNAL(triggered()),this,SLOT(SomeFucntion()))
In SomeFucntion I need to know which shortcut was pressed....Is there anyway of knowing that ?
You could try a more elaborate pattern with QSignalMapper that avoids the need to define as many actions as many shortcut you need, but requires c++11 (at least this implementation).
In the constructor of your window use the following code to declare your QShortcut objects and a QSignalMapper:
QSignalMapper* signalMapper = new QSignalMapper(this);
QShortcut* sc1 = new QShortcut(QKeySequence(Qt::CTRL + Qt::Key_N), this);
QShortcut* sc2 = new QShortcut(QKeySequence(Qt::CTRL + Qt::Key_T), this);
connect(sc1, &QShortcut::activated, signalMapper, static_cast<void (QSignalMapper::*)(void)>(&QSignalMapper::map));
connect(sc2, &QShortcut::activated, signalMapper, static_cast<void (QSignalMapper::*)(void)>(&QSignalMapper::map));
signalMapper->setMapping(sc1, sc1);
signalMapper->setMapping(sc2, sc2);
QAction* action = new QAction();
connect(signalMapper, static_cast<void (QSignalMapper::*)(QObject*)>(&QSignalMapper::mapped),
[action](QObject *object){
QShortcut* sc = qobject_cast<QShortcut*>(object);
if (sc)
{
action->setData(sc->key().toString());
action->trigger();
}
});
connect(action, &QAction::triggered, this, &MainWindow::doStuff);
The 3rd connection is required because of the way QSignalMapper works: when a shortcut is activated, it will be notified to the QSignalMapper thanks to the 1st and 2nd connections, that will trigger the map() slot.
The QSignalMapper::map() slot will scan its mappings, made with the setMapping() API, whose first argument is the mapped object, and the second one is the parameter that will be used to emit the mapped() slot of the QSignalMapper, once the emitting object is identified. To do so, it uses the sender() method and simply compares the pointer returned to the mapped QObject pointers you provided as mappings.
Once the QObject is identified, QSignalMapper will emit the QSignalMapper::mapped(QObject*) signal, whose argument is the second argument given to setMapping, and in this case it the same as the first one, that is again a pointer to the QShortcut that was activated.
I used a lambda to catch this signal, and inside this lambda I simply check that the parameter given is a QShortcut pointer, and store its key sequence inside the data member of the QAction before triggering the action itself. The QAction::trigger() slot will then emit the QAction::triggered() signal that will in turn invoke your custom slot, in this case doStuff(). There you can retrieve the key sequence and do what you want with it.
So your slot implementation should look similar to this one:
void MainWindow::doStuff()
{
// use sender() to fetch data from action
QAction* act = qobject_cast<QAction*>(sender());
if (act)
{
QString sequence = act->data().toString();
// debug output will show you the triggering key sequence
qDebug() << sequence;
// use sequence string to determine which shortcut was used
// On Mike hint: better to reset data after use :)
act.setData(QVariant());
}
}
Note that I'm using a mapping based on QObject pointers. In this way you can reuse the signalMapper instance to connect events from other kind of QObjects (e.g. QPushButtons) and identify them in your custom slot as well setting a proper value for the QAction data member, that can store a generic QVariant istance.
Also when using QShortcut, be aware of their contex, that is when they are active, as it could be at widget or a window scope.
Unfortunately this pattern violates pure oop principles, but could be better than managing many actions (icon, text, tooltip etc...) for the same purpose.
EDIT: to answer comments
First of all, let me clarify that you can of course skip the use of QSignalMapper at all. This is just a possible solution (not the better, maybe an overkill... but not really worse in terms of performance).
A simpler way, as pointed by Mike in the comments consists in using lambdas for each QShotcut::activated signal, but this will result in copy/paste code, that I always try to avoid.
You can instead define a custom slot inside the MainWindow and use sender() to catch the QShortcut and prepare the action before triggering it.
Anyway, QSignalMapper IMHO, better explains what you are doing (from a semantic point of view) and is more flexible in case you need to expand the connection to other QObjects, supporting also other type of mappings.
Furthermore, but this is related to my personal taste, I like the idea to have fragments of code that are logically tied condensed into small snippets, instead of have it sparse among several slot/functions because it makes it easier to read and to trace back when I need to change it, of course only if this does not hurt the quality of code itself.
You should create a separate QAction for each shortcut and group them using a QSignalMapper.
I have checked my code several times and i still can't get why it is not working.
I use a QComboBox connected to a slot in the class like this :
this->choixCam = new QComboBox;
this->choixCam->addItem("Camera 1");
this->choixCam->addItem("Camera 2");
this->choixCam->addItem("Camera 3");
this->choixCam->addItem("All cameras");
QObject::connect(this->choixCam, SIGNAL(currentIndexChanged(int)), this, SLOT(this->selectCam(int)));
This previous part of code is defined is the constructor of my class MainWindows, called in the main. The definition in the header file is the following :
public:
QComboBox* choixCam;
public slots:
void selectCam(int choixCam);
I tried with successfully to run the slot from another signal.
Using the signal with QString, the signal activated(int) or trying an exemple find on the net didn't work neither. Signals/slots mecanism also work for QButton and QSpinBox.
I am running out of idea. Some help would be very appreciate.
Thank you.
#eyllanesc answer should work. Just change SLOT(this->selectCam(int)) to SLOT(selectCam(int)).
But why isnt it the same for QT?
Lets have a look at the connect method:
QMetaObject::Connection QObject::connect(const QObject *sender, const char *signal,const QObject *receiver, const char *method,
Qt::ConnectionType type)
(https://github.com/qt/qtbase/blob/e4c39d5e1e7ee8c2bba273e6d613ec519b7fa9c2/src/corelib/kernel/qobject.cpp#L2659)
and at the SIGNAl and SLOT definition:
#define SLOT(a) "1"#a
#define SIGNAL(a) "2"#a
QT uses c-strings to identify the signals and slots for qobjects.
These strings are used as keywords in some kind of dictionary over all qobjects, signals and slots.
Just try std::cout << SIGNAL(some text) << std::endl; to see what SIGNAL and SLOT do.
Thats why can call connect even without SIGNAL and SLOT:
connect(this->choixCam, "2currentIndexChanged(int)", this, "1selectCam(int)");
Now you know that
SLOT(this->selectCam(int)) will produce "1this->selectCam(int)" as keyword instead of "1selectCam(int)"
The SIGNAL and SLOT definitions are used because most IDEs disable C++ autocompletion inside quotation marks, which makes it hard to write the correct function signature.
I'm working on Qt 4.8.5. I'm using a QWizard structure with its QWizardPages (lets name them wp1, wp2, wp3,...). I need to pass one value from wp2 to wp4 but every time I try it, I get an empty string :(
The value I need is on a variable (QString sVar;) so not a widget and I've tried some things:
Using RegisterField with the wizardpage itselfs (as its still a type of qwidget) like this: registerField("myField",this); but ofcourse when i go to wp4 and try to qDebug()<< "data: " << field("myField").toString();it is empty.
I've see in some forums ppl saying that you can create a Q_PROPERTY and then use the register field. I've set it as Q_PROPERTY sData READ getData() WRITE setDATA() and then with registerField("myfield, this, ...and here I have a problem because i expect sData to apear but it doesn't.
So... any idea about how can I achieve this using registerField (I know I can also create my own slot and signal, emit it from wp2 and catch it up on wp4 but I would like to avoid it if possible)
Added the solution:
Class A.h:
class ClassA: public QWizardPage
{
Q_OBJECT
Q_PROPERTY(QString sAP READ getAP WRITE setAP)
....
public:
QString getAP() const {return AP;}
void setAP(QString s){AP=s;};
private:
QString AP;
Class A constructor:
registerField("AP_field",this, "sAP", SIGNAL(APChanged()));
Class A ::initializePage() function:
switch(m_iVar)
{
case 0 :...
break;
case 1:
setAP("AP1");
emit APChanged();
break;
}
And then in Class B (Where you need to know that data):
qDebug() << " AP QPROPERTY = " <<field ("AP_Field").toString();
According to the docs:
When we create a field using QWizardPage::registerField(), we pass a
unique field name and a widget. We can also provide a Qt property name
and a "changed" signal (a signal that is emitted when the property
changes) as third and fourth arguments; however, this is not necessary
for the most common Qt widgets, such as QLineEdit, QCheckBox, and
QComboBox, because QWizard knows which properties to look for.
So you still need a signal, but Qt will handle necessary connections for you and will catch your new value as you change it. You have to register like this:
registerField("myField", this, "myProperty", SIGNAL(myPropertyChanged()));
Then you have to remember to emit the signal each time you change your variable, and of course register it as a property.
This works from some but not all widgets that emit a signal. For QDoubleSpinWidgets,
QWizard::setDefaultProperty("QDoubleSpinBox", "value", SIGNAL(valueChanged(double)));
This is because the valueChanged() is for QString and double....does not know which value to take without the parameter specifying:
"Every time the value changes QDoubleSpinBox emits two valueChanged() signals, one taking providing a double and the other a QString. The QString overload provides the value with both prefix() and suffix(). The current value can be fetched with value() and set with setValue()." doc.qt.io/qt-5/qdoublespinbox.html I hope this never troubles others and this complete solution, no warnings, errors nor unpredictable behaviour.
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 some dynamically added QWidgets and I want to carry out some task when they are changed.
I think I can't use connect() because I also need the name of the QWidget that triggered the change.
How can I also see which QWidget was changed and still catch the value change event with a common handler?
The quick-and-dirty way is to use connect() as usual, and then in your slot method, call sender() to find out which object sent the signal. For example:
// slot method that you've connected all of your widgets' stateChanged(int) signals to
void MyClass :: someWidgetsStateChanged(int newState)
{
const QObject * s = sender();
if (dynamic_cast<const QCheckBox *>(s) == _myFirstCheckbox) printf("First checkbox is now %s\n", newState?"Checked":"unchecked");
else if (dynamic_cast<const QCheckBox *>(s) == _mySecondCheckbox) printf("Second checkbox is now %s\n", newState?"Checked":"unchecked");
[... and so on...]
}
Note that the reason this is considered "dirty" is that it breaks encapsulation. In particular, the someWidgetsStateChanged() method above now behaves differently depending on which object generated the signal, and so if e.g. at some point in the future you connected a QPushButton::clicked() (or whatever) to that same slot, you'd probably have to update the someWidgetsStateChanged() implementation to handle it appropriately. Still, this works and doesn't require a lot of effort to implement.
Use this to catch events before they are passed to QObject subclass instances:
http://qt-project.org/doc/qt-4.8/qobject.html#installEventFilter
After some additional thinking I arrived at saying why not to extend these controllers?
So that I could hook them to the parent object using parent() or using a custom constructor.
It requires potentially though that I define them as friend classes...