To connect signals to slots, as far as I know, the parameters of the signal need to match the parameters of the slot. So for example:
connect(dockWidget->titleBarWidget(), SIGNAL(closeButtonClicked()), ui->sideControls, SLOT(closeDockWidget()));
But what if I want to have a signal call a slot that has a different amount of parameters, but always pass a constant value into the slot. For example, using the above piece of code:
connect(dockWidget->titleBarWidget(), SIGNAL(closeButtonClicked()), ui->sideControls, SLOT(setDockWidget(false)));
Or in other words, whenever the button is pressed, it calls the setDockWidget() function with the false parameter. Is this possible?
You can use lambda with desired call with constant argument. Example:
connect(obj, &ObjType::signalName, [this]() { desiredCall(constantArgument); });
More about new connect syntax: https://wiki.qt.io/New_Signal_Slot_Syntax.
No, it is not possible. You are only allowed to connect slots with less or equal argument count, than in corresponding signal. (see documentation)
You have to create proxy slot, that will call desired one.
In a way, yes, you can. But it's not very powerful : just declare the setDockWidget this way :
[virtual] void setDockWidget(bool state=false) ;
And declare the connection this way :
connect(emitter, SIGNAL(closeButtonClicked()), receiver, SLOT(setDockWidget()));
setDockWidget called without arguments take the default ones.
Related
I am very new to QT and C++, I am trying to connect Line edit to progress bar so when I enter some integer value to the Line Edit, progress bar will show it. I could not achieve it. This is what I was trying:
connect(ui->batterycapacity,&QLineEdit::textChanged, ui->progressBar,ui->progressBar->setValue(ui->batterycapacity->text().toInt()));
or this:
connect(ui->batterycapacity,&QLineEdit::textChanged, ui->progressBar,ui->progressBar->&QProgressBar::setValue(ui->batterycapacity->text().toInt()));
batterycapacity is my Line Edit. How can I connect those 2 together? Thanks beforehand.
You're close. As the signal's argument differs from the slot's argument you need to adapt it with toInt, but you cannot simply stick arbitrary code in an argument and expect C++ to execute it when the signal changes.
You need to wrap your snippet in a lambda expression:
connect(ui->batterycapacity, &QLineEdit::textChanged, ui->progressBar,
[=](const QString& text) {
ui->progressBar->setValue(text.toInt()));
});
The lambda will receive the argument of the textChanged signal and pass that to the setValue method.
The [=] bit at the front tells the compiler to capture the value of ui by value so it is accessible inside the lambda.
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 am using QCustomPlot where I am trying to write a code that will rescale my axes once the user press the mouse and drags. I did:
connect(ui->plot, SIGNAL(mousePress(QMouseEvent *event)), this, SLOT(mousedrag(QMouseEvent*)));
and I keep getting:
QObject::connect: No such signal QCustomPlot::mousePress(QMouseEvent
*event)
But mouseWheel(QWheelEvent*) and both mouseWheel and mousePress have signals declared in the QCustomPlot library.
Where am I going wrong? Also if someone has a better signal to trigger my function mousedrag(QMouseEvent*) which rescales the the y2 axis according to y1 axis I am open for suggestions.
The signal signature passed to connect is invalid. The parameter names are not a part of the signature. You should also remove any whitespace so that connect doesn't have to normalize the signatures. A normalized signature has no unnecessary whitespace and outermost const and reference must be removed, e.g. SIGNAL(textChanged(QString)), not SIGNAL(textChanged(const QString &)).
remove
vvvvv
connect(ui->plot, SIGNAL(mousePress(QMouseEvent *event)), this,
SLOT(mousedrag(QMouseEvent*)));
Do the below instead:
// Qt 5
connect(ui->plot, &QCustomPlot::mousePress, this, &MyClass::mousedrag);
// Qt 4
connect(ui->plot, SIGNAL(mousePress(QMouseEvent*)), SLOT(mousedrag(QMouseEvent*));
Sidebar
TL;DR: This sort of API design is essentially a bug.
Events and signal/slot mechanism are different paradigms that the QCustomPlot's design mangles together. The slots connected to these signals can be used in very specific and limited ways only. You have to use them exactly as if they were overloads in a derived class. This means:
Each signal must have either 0 or 1 slots connected to it.
The connections must be direct or automatic to an object in the same thread.
You cannot use queued connections: by the time the control returns to the event loop, the event has been destroyed and the slot/functor will be using a dangling pointer.
When using the "old" signals/slot connection syntax, i.e. the one using the SIGNAL and SLOT macros in the connect() statement, you shall not provide the names of the parameters, only their types.
In other words:
SIGNAL(mousePress(QMouseEvent *event)) // WRONG, parameter name in there!
SIGNAL(mousePress(QMouseEvent *)) // GOOD
SIGNAL(mousePress(QMouseEvent*)) // BETTER: already normalized
So simply change your statement to
connect( ui->plot, SIGNAL(mousePress(QMouseEvent*)),
this, SLOT(mousedrag(QMouseEvent*)) );
I understand that we could use QSignalMapper to collect a set of parameterless signals, and re-emit them with integer, string or widget parameters corresponding to the object that sent the signal.
But could we do the reverse?
For example, is it possible to achieve:
connect(control,startVehicle(0),vehcileList[0],startReceived());
connect(control,startVehicle(1),vehcileList[1],startReceived());
connect(control,startVehicle(2),vehcileList[2],startReceived());
instead of having 3 different signals from control as
startVehicle_1();
startVehicle_2();
startVehicle_3();
There is a simpler way:
connect(control, SIGNAL(startVehicle(int)), this, SLOT(startReceived(i)));
//in startReceived(i) slot
vehcileList[i]->startReceived();
I have a block of spin controls which change individual elements of an array
Rather than having separate receiver slot functions, I wanted to just specify which control sent the message in the signal
You can do this with a QSignalMapper - but is there anyway of doing it simply as below?
spin0 = new QDoubleSpinBox;
connect(spin0,SIGNAL(valueChanged(double)),this,SLOT(handler(0,double));
spin1 = new QDoubleSpinBox;
connect(spin1,SIGNAL(valueChanged(double)),this,SLOT(handler(1,double));
....
private slot:
void handler(int element,double value);
From any slot handler you can can use sender() to get a pointer to the object that sent the signal. Then you can use the objectName() property to communicate any further identifying information.
I don't believe so, at least not using that syntax ... the SIGNAL and SLOT macros turn their arguments into strings which are then parsed and used by the Qt runtime to look-up the associated functions and/or class methods in the tables created by moc during the pre-processing phase of compilation. So if you encoded a default argument into the SLOT macro, then that's not a valid function signature that can be used by Qt for run-time lookup of the actual slot function in the moc-generated function tables.