Hi I am fairly new to Qt scene and I'm having trouble updating my comboBox2 based on comboBox1 selection.
Everytime I make a change in comboBox1, my app crashed, saying access violation. It's probably very straightforward but here's my code: In this case, the initial comboBox1 has "Car" and "Food". Whenever I switch to "Food", I want my comboBox2 to populate the item "Egg".
Any idea what went wrong ?
main.h
class main:
{
Q_OBJECT
public:
main() {}
public slots :
private slots:
void onComboBoxIndexChanged();
private:
QComboBox* comboBox2;
void run();
};
main.cpp
void main::run()
{
QWidget *w = new QWidget();
QComboBox *comboBox1 = new QComboBox();
QComboBox *comboBox2 = new QComboBox();
comboBox1->addItem("Car");
comboBox1->addItem("Food");
connect(comboBox1, SIGNAL(currentIndexChanged(int)), this, SLOT(onComboBoxIndexChanged()));
...
}
void main::onComboBoxIndexChanged()
{
QComboBox* combo = dynamic_cast<QComboBox*>(sender());
if (combo == nullptr)
{
return;
}
comboBox2->addItem("Egg");
}
You didn't fix your typo correctly. There's three things I see wrong, and I would've thought the third one would prevent this from compiling.
First, main.h says that your class name is "main", but in main.cpp, your class is WIPGui. Clearly one of those files isn't the right one. I'm going to proceed assuming that your actual main.h file defines the WIPGui class, but otherwise looks the same.
Second, as Mike tried to point out, in your run function, you have this:
QComboBox *comboBox2 = new QComboBox();
That's creating a local variable in your "run" method; it is not assigning to your class member variable comboBox2. What you want is:
comboBox2 = new QComboBox();
Third, your connect statement shouldn't compile based on the code we're seeing:
connect(comboBox, SIGNAL(currentIndexChanged(int)), this, SLOT(onComboBoxIndexChanged()));
The "comboBox" variable doesn't exist anywhere in this code. If you've actually used "comboBox1" in the connect statement, but this is just another typo in the code you've presented here, then the connect statement is fine. If this is a cut-and-paste as-is, then I don't see how this compiles.
Assuming that you've used "comboBox1" in the connect statement, then the real problem is that you're never assigning to the member variable "comboBox2" and when your slot tries to use it, you get a crash.
Related
I have a QTreeWidget with two columns: one for property name and one for property value. The value can be edited via a widget. For example one property is Animal. When you double click the property value column I make a (custom) combobox with different animal types via this code:
QTreeWidgetItemComboBox* comboBox = new QTreeWidgetItemComboBox(treeItem, 1);
// treeitem is a pointer to the row that is double clicked
comboBox->addItems(QStringList() << "Bird" << "Fish" << "Ape");
ui.treeWidget->setItemWidget(treeItem, 1, comboBox);
When the row loses focus I remove the widget again (and the value is put as text of the QTreeWidgetItem). For removing I use
ui.treeWidget->removeItemWidget(treeItem, 1);
Now I'm wondering, since I've used new, do I neww to also delete the widget. I know this is the case if you use takeChild(i) for example. But I didn't see something similar for an itemWidget.
Do I need to delete it what would be the right order?
QTreeWidgetItemComboBox* comboBox = ui.treeWidget->itemWidget(treeItem,1);
// Do I need a cast here since the return type is QWidget*
ui.treeWidget->removeItemWidget(treeItem, 1);
delete comboBox;
or
QTreeWidgetItemComboBox* comboBox = ui.treeWidget->itemWidget(treeItem,1);
// Do I need a cast here since the return type is QWidget*
delete comboBox;
ui.treeWidget->removeItemWidget(treeItem, 1);
When the widget is added ot the QTreeWidget, it indeed takes ownership of the widget. But it only implies that the widget will be deleted when the parent is destroyed.
So if you just want to remove the widget while keeping the parent QTreeWidget alive, you indeed have to delete it manually.
The correct solution is the first one, remove the widget from the QTreeWidget first, and then delete it with one of the following ways:
delete comboBox;
comboBox = nullptr;
or:
comboBox.deleteLater();
The second one is preferred.
EDIT:
I don't change the answer since it could be a dishonest to change what was already accepted, ...
But as #Scopchanov mentioned, by reading the source code, the QTreeWidget::removeItemWidget() already calls the deleteLater() method on the old widget. We don't have to do it manually.
Anyway, the documentation says it is safe to call deleteLater() more than once:
Note: It is safe to call this function more than once; when the first deferred deletion event is delivered, any pending events for the object are removed from the event queue.
Therefore, manually deleting the widget after calling QTreeWidget::removeItemWidget() becomes useless.
You are not allowed to delete the item widget as the tree is the owner of the widget once it has been passed to the tree with setItemWidget().
From the documentation of setItemWidget():
Note: The tree takes ownership of the widget.
EDIT: In case you want a new widget, simply call setItemWidget() once more or call removeItemWidget() in case you do not need the widget anymore. The tree will ensure that no memory gets lost.
Explaination
You should not manually delete a widget, added to a QTreeWidget, since it is automatically deleted either by
destructing its parent tree widget
This is a direct consequence of the Qt's parent-child mechanism.
calling QTreeWidget::removeItemWidget anytime the tree widget still lives.
This one is not so obvious, since the documentation simply sais:
Removes the widget set in the given item in the given column.
However, looking at the source code it becomes pretty clear what is indeed happening, i.e.
QTreeWidget::removeItemWidget calls QTreeWidget::setItemWidget with a null pointer (no widget)
inline void QTreeWidget::removeItemWidget(QTreeWidgetItem *item, int column)
{ setItemWidget(item, column, nullptr); }
QTreeWidget::setItemWidget in turn calls QAbstractItemView::setIndexWidget
void QTreeWidget::setItemWidget(QTreeWidgetItem *item, int column, QWidget *widget)
{
Q_D(QTreeWidget);
QAbstractItemView::setIndexWidget(d->index(item, column), widget);
}
Finally QAbstractItemView::setIndexWidget checks if there is already a widget at this index, and if there is one, calls its deleteLater method
if (QWidget *oldWidget = indexWidget(index)) {
d->persistent.remove(oldWidget);
d->removeEditor(oldWidget);
oldWidget->removeEventFilter(this);
oldWidget->deleteLater();
}
Simply put (and this should be made clear in the documentation of both methods of QTreeWidget), any call to QTreeWidget::setItemWidget or QTreeWidget::removeItemWidget deletes the widget (if any) already set for the item.
Example
Here is a simple example I have prepared for you in order to demonstrate the described behaviour:
#include <QApplication>
#include <QBoxLayout>
#include <QTreeWidget>
#include <QComboBox>
#include <QPushButton>
struct MainWindow : public QWidget
{
MainWindow(QWidget *parent = nullptr) : QWidget(parent) {
auto *l = new QVBoxLayout(this);
auto *treeWidget = new QTreeWidget(this);
auto *item = new QTreeWidgetItem(treeWidget);
auto *button = new QPushButton(tr("Remove combo box"), this);
auto *comboBox = new QComboBox();
comboBox->addItems(QStringList() << "Bird" << "Fish" << "Ape");
treeWidget->setItemWidget(item, 0, comboBox);
l->addWidget(button);
l->addWidget(treeWidget);
connect(comboBox, &QComboBox::destroyed, [](){
qDebug("The combo box is gone.");
});
connect(button, &QPushButton::clicked, [treeWidget, item](){
treeWidget->removeItemWidget(item, 0);
});
resize(400, 300);
}
};
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Result
The described ways of destroyng the widget could be tested with the application
Simply closing the window destroys the tree widget together with its child combo box, hence the combo box's destroyed signal is emitted and the lambda prints
The combo box is gone.
After pressing the button the lambda function connected to its clicked signal is called, which removes the combo box from the tree widget. Because the combo box is deleted (automatically) as well, the lambda from the second connect statement is called, which also prints
The combo box is gone.
In a Qt GUI I'm trying to connect a TextEdit with a label so that when the user types something, the label updates it's text. Here is what I've tried:
void MainWindow ::updatelabel()
{
ui->label->setText("Hello");
}
void MainWindow::changeTextColor()
{
QString textEdit = ui->textEdit->toPlainText();
QString label = ui->label->text();
connect(textEdit, SIGNAL(textChanged()), label, SLOT(updateLabel()));
}
This gives me an error though:
error: no matching function for call to 'MainWindow::connect(QString&, const char*, QString&, const char*)'
connect(textEdit, SIGNAL(textChanged()), label, SLOT(updateLabel()));
^
What am I doing wrong and how can I fix it? Thanks!
You have a few problems in your code. Here's changed code with comments explaining it:
// make sure updateLabel is declared under slots: tag in .h file
void MainWindow ::updatelabel()
{
// set label text to be the text in the text edit when this slot is called
ui->label->setText(ui->textEdit->toPlainText());
}
// this is a very suspicious method. Where do you call it from?
// I changed its name to better indicate what it does.
void MainWindow::initializeUpdatingLabel()
{
//QString textEdit = ui->textEdit->toPlainText(); // not used
//QString label = ui->label->text(); // not used
// when ever textChanged is emitted, call our updatelabel slot
connect(ui->textEdit, SIGNAL(textChanged()),
this, SLOT(updatelabel())); // updateLabel or updatelabel??!
}
A practical hint: when ever you use SIGNAL and SLOT macros, let Qt Creator to autocomplete them. If you type them by hand, and make a typo, you don't get a compile time error, instead there will be a runtime warning print about having no a matching signal/slot.
Or, assuming you are using Qt5 and C++11 capable compiler, you can use the new connect syntax, which will give you compiler error if you get it wrong. First add line CONFIG += C++11 to the .pro file, and then do the connect like this:
void MainWindow::initializeUpdatingLabel()
{
connect(ui->textEdit, &QTextEdit::textChanged,
this, &MainWindow::updatelabel);
}
Now if you for example actually have no updateLabel method, you get compile time error, which is much nicer than runtime message which you might not even notice. You could also replace the whole updatelabel method with a lambda, but that goes out of the scope of this question/answer.
You're connecting to the wrong textEdit and label variables in that method:
- connect(textEdit, SIGNAL(textChanged()), label, SLOT(updateLabel()));
+ connect(ui->textEdit, SIGNAL(textChanged()), this, SLOT(updateLabel()));
A QString is not a widget with signals and slots. You want the actual widget from ui, ui->textEdit, and this for the current class which contains updateLabel().
Edits: fix mistakes I made because I answered while tired.
I have a simple MainWindow which has a button and an LineEdit. When I type something and click a button, a new Dialog appears with a label that is supposed to display the string I typed.
So basically, I have trouble sending information to another UI.
I tried working with the new class with a string variable, but it didn't work.
I will try to give an example of what I want to do.
//ui2 Dialog
ui2->label->setText(ui->LineEdit->text());
Ui is a an private variable, so it's not accessible from another class.
//mainwindow.cpp
MainWindow::MainWindow(QWidget*){
this->_dialog = new Dialog(this);
//...
}
MainWindow::on_pushButton_clicked(){
_dialog->_labe->setText(ui->lineEdit->text());
}
//dialog.h
class Dialog{
public:
QLabel* _label;
Dialog(QWidget* ){
_label = ui->label;
}
}
I'm trying to connect a combo box value and a label such that when the combo box changes the label reflects that. I have googled my heart out trying to find an answer but, as of yet, nothing has worked; I still get the error:no matching function for call to mainWindow::connect(QComboBox*&, const char [38], QString*, const char [26])
I have tried QObject::connect, QWidget::connect and anything else dealing with Qt, but to no avail.
Creating a label that says the combo box value is not my final intention for the program. Rather, I wish to get it working with a simple label then change it to what I want it to display (thus the tempLabel).
mainwindow.h:
class MainWindow : public QMainWindow
{
public:
MainWindow();
private slots:
QString getClass(QComboBox *box);
};
mainwindow.cpp:
MainWindow::MainWindow()
{
QString qMathClassName;
QComboBox* mathClassCombo = new QComboBox;
QLabel* label = new QLabel(qMathClassName);
// omitting layout code...
connect(mathClassCombo, SIGNAL(currentIndexChanged(const QString &)),
&qMathClassName, SLOT(getClass(mathClassCombo)));
}
QString MainWindow::getClass(QComboBox *box)
{
return box->currentText();
}
Any help would be greatly appreciated!
You are connecting a signal to a slot with a different signature. You have to change your slot to something like
getClass(const QString &)
to match currentIndexChanged signal.
I think you need to read Qt's signals and slots documentation. Again, if you've already done so. Pay special attention to their examples.
I think that you had these misconceptions about Qt in C++:
That QLabel takes a reference to a QString, and that it will update its text when that string changes. It won't. QLabel will display the value of the string when you give it the string. That is the only time it will update.
That objects constructed on the stack will not be destroyed at the end of the function. They will not. At the end of the constructor, qMathClassName will be destroyed and any reference to it will become invalid. Thus, you'd not want to make a connection to it, even if you could.
That the third argument of QObject::connect is a pointer to a place to put the return value for the slot. It's not. The third argument is a pointer to the QObject on which to call the slot. The return value of a slot is unused for any calls made to it via QObject::connect.
That you can bind values to slots in your connection. Unfortunately not. Within the SLOT macro, you must put the function signature of the slot. You may not reference any variables. The arguments section must have only class names. That is SLOT(getClass(QComboBox*)), not SLOT(getClass(mathClassCombo)).
The simplest way to ensure the contents of a combo box are displayed in a label are this:
QComboBox* mathClassCombo = new QComboBox;
QLabel* tempLabel = new QLabel;
connect(mathClassCombo, SIGNAL(currentIndexChanged(const QString&)),
tempLabel, SLOT(setText(const QString&)));
If you want to do something more complicated, I recommend just making a slot on your window that can handle those complications. For example:
mainwindow.h:
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow();
private slots:
void updateLabelText(const QString& className);
private:
QComboBox* mathClassCombo;
QLabel* tempLabel;
}
mainwindow.cpp:
MainWindow::MainWindow()
{
mathClassCombo = new QComboBox;
tempLabel = new QLabel;
// omitting layout code...
connect(mathClassCombo, SIGNAL(currentIndexChanged(const QString&)),
this, SLOT(updateLabelText(const QString&)));
}
void MainWindow::updateLabelText(const QString& className)
{
QString newLabelString = className + " is the best class ever!";
tempLabel->setCurrentText(newLabelString);
}
Im trying to figure this error out. I have a simple application made with Qt Creator.
I have three buttons and 2 of them are not enabled. Then when push the first button i want to make them visible, but when i push the button, windows error occures : "program stopped working". the program compiles and does everything else.
QPushButton *dealButton = new QPushButton(tr("Deal cards"));
dealButton->show();
QPushButton *hitButton = new QPushButton(tr("HIT"));
hitButton->show();
hitButton->setEnabled(false);
QPushButton *standButton = new QPushButton(tr("STAND"));
standButton->show();
standButton->setEnabled(false);
...
connect(dealButton, SIGNAL(clicked()), this, SLOT(dealCards()));
...
void MainWindow::dealCards()
{
hitButton->setEnabled(true);
standButton->setEnabled(true);
}
thats the code.
The problem is that you are re-declaring dealButton and the others in your constructor (or whatever function it is that has the new calls you're showing).
You should have in your class definition:
private: // probably
QPushButton *dealButton;
And in your constructor or gui init code:
dealButton = new QPushButton(...); // note: not QPushButton *dealButton = ...
What you have now is creating a new variable called dealButton that is local to that scope (function). That variable is hiding (masking) the class's member.