I am working in Qt4.7, and I have a QListWidget in my dialog. I have a QString that needs to match the current text in the row of this widget (the individual rows are editable). Looking at the signals associated with QListWidget, there seem to be signals for when a different index is selected but none for when the text of a the currently selected row changes. I thought currentTextChanged(QString) would do it, but it didn't. I also thought to try to connect each individual row to something, but QListWidgetItem doesn't have any built-in signals. Does anyone know of a way to do this? Thanks!
At first it seems like QListWidget::itemChanged is the way to go, but soon you run into a problem: the signal is sent for everything - inserts, changing colors, checking boxes, and anything else that "changes" the item! Predelnik pointed that out in his answer. Some people have tried to put in flags and filter everywhere by intercepting various signals to find out if editing was the actual event. It gets very messy.
There is also QAbstractItemModel::dataChanged , which would seem like a good solution. It even has a parameter "const QVector& lstRoles" so you could scan for Qt::EditRole and see if it was really edited. Alas, there's a catch - it gets called for everything just like QListWidget::itemChanged and unfortunately, for QListWidget anyway, the roles parameter is always empty when it's called (I tried it). So much for that idea...
Fortunately, there's still hope... This solution does the trick! :
http://falsinsoft.blogspot.com/2013/11/qlistwidget-and-item-edit-event.html
He uses QAbstractItemDelegate::closeEditor, but I prefer using QAbstractItemDelegate::commitData.
So make a connect like so...
connect(ui.pLstItems->itemDelegate(), &QAbstractItemDelegate::commitData, this, &MyWidget::OnLstItemsCommitData);
Then implement the slot like this...
void MyWidget::OnLstItemsCommitData(QWidget* pLineEdit)
{
QString strNewText = reinterpret_cast<QLineEdit*>(pLineEdit)->text();
int nRow = ui.pLstItems->currentRow();
// do whatever you need here....
}
Now you have a slot that gets called only when the list item's text has been edited!
I guess you need to look into the following signal:
void QListWidget::itemChanged(QListWidgetItem * item)
But be careful because it's being sent every time some property of item changed, not only text. I remember when we ran into the problem once when we changed item colors and got tons of false positive slots called because of that. If you need more fine tuning I guess it's better to write model/view classes yourself and not rely on QListWidget.
Related
I've got an std::string object called str;
I've also got an QLineEdit object called line_edit.
I need that str reflects whatever the user writes in line_edit, this I know how to do trough signals and slots.
But I also need that whenever str changes , QLineEdit automatically displays the new contents of str.
How can I do this?
Is it MVC what I need? I've been reading about it but I can't get it yet.
Also, examples I've read try to keep mutually updated subobjects of QWidget
which makes me think there is some magic happening in there.
How can I achieve that reactivity?
First of all it might be easier to use QString instead of std::string.
You can call line_edit->setText(str); to update line_edit from your code.
You can use the signal QLineEdit::textChanged to modify the content of str when writing to the QLineEdit.
There are multiple ways of handling signals, one way would be to use QObject::connect
It might look like this: QObject::connect(line_edit, &QLineEdit::textChanged, this, &YourClassName::setText);
And then you create setText(){ str = line_edit->text}
I am subclassing QFileDialog to try to get some custom behavior. I would like to connect to signals emitted by components of the dialog, e.g. the textEdited signal when the file name line edit is manually edited. I understand that QFileDialog emits some signals itself, but these do not cover the cases I would like to respond to.
I have two ways about this I can think of, but don't know how to implement. One is to somehow attain a reference to the component to connect to it's signal. The other would be something with event filters, but the event source is the dialog itself, so I don't know how to determine where mouse clicks or key presses occur.
Are either of these methods feasible? Or another way?
Here is one option (your first suggestion):
dialog = QFileDialog()
layout = dialog.layout()
# for i in range(layout.rowCount()):
# for j in range(layout.columnCount()):
# try:
# print i,j
# print layout.itemAtPosition(i,j).widget()
# except:
# pass
line_edit = layout.itemAtPosition(2,1).widget()
line_edit.setText('Hello Stack Overflow')
dialog.exec_()
This gives you access to the QLineEdit in the dialog, which has a bunch of signals you can connect to.
I've also included the code I used to find this widget. I just iterated over the widgets in the layout of the dialog and found the indices of the one I was after. So if you need access to anything else in the dialog, you should be able to find it pretty easily!
Downside to this method: If the layout changes in a future version of Qt, this will break. I suppose you could make the algorithm more robust by looking for widgets that are instances of QLineEdit, but there are always risks with hacky approaches like this!
I am subclassing QDoubleSpinBox to add some features (like incrementing the value based on the location of the cursor in the lineedit) and to change some features I find annoying. One of the latter is that intermediate values are emitted: e.g. if you want to enter the value 323 it will emit 3 then 32 then finally 323. I'd like to set it to only emit on entry (i.e. only actually change value on entry).
Anyway, I can't figure out how to capture these intermediate edits. I overrode setValue to see if I could stop it there somehow, but it apparently isn't called (or at least my override isn't). I'm not sure how the value is actually getting set while editing in line edit.
More generally, the logic of this box escapes me. Is there some documentation that explains e.g. "if you type a digit into the lineedit then this series of routines is called... while if you hit the up arrow, this series of routines is called?"
In case it matters, I'm using PyQt5
EDIT: Here is another case in which having access to this is important. Say I want to implement an undo/redo structure for the box. The only way I can think of to get access to the changed values is to connect to the valueChanged signal. But if I'm subclassing the box it seems a little convoluted to listen for a signal rather than just watch the value change 'internally' Or am I missing something here?
You could use the following signal:
void QAbstractSpinBox::editingFinished() [signal]
This signal is emitted editing is finished. This happens when the spinbox loses focus and when enter is pressed.
based on the documentation of QAbstractSpinBox:
http://qt-project.org/doc/qt-5.1/qtwidgets/qabstractspinbox.html#editingFinished
There is nothing that combines the arrow based changes and the editingFinished changes.
My use case was to let the user enter the value without getting the signal on each new digit, while still making ↑, ↓, Page Up, Page Down keys and arrow buttons work as usual, emitting the signal on each activation.
QAbstractSpinBox::editingFinished signal doesn't provide this functionality: it's only ever emitted when focus is lost or Return/Enter is pressed.
What does work exactly as I need is the keyboardTracking property of QAbstractSpinBox. If it's true (the default), the spinbox emits valueChanged on each digit typed. If you set it to false, it behaves exactly as I described in the beginning of this answer.
I'm a beginner to Qt and am making (or at least trying to make) a basic calculator. If I understand correctly, when doing this:
connect(my_button_4, SIGNAL(clicked()), this, SLOT(writeNumberLbl("4")));
The "4" is not accessible (rather, only its type is) in writeNumberLbl. Basically, I would like so that when the button is clicked, the label sets its text to "4". However, I have the numbers 0 to 9, so I wanted to do:
connect(my_button_0, SIGNAL(clicked()), this, SLOT(writeNumberLbl("0")));
connect(my_button_1, SIGNAL(clicked()), this, SLOT(writeNumberLbl("1")));
...
connect(my_button_9, SIGNAL(clicked()), this, SLOT(writeNumberLbl("9")));
My writeNumberLbl function is:
void Calculator::preWriteVal(QChar val)
{
QString curVal = ui.lbl_output->text();
curVal += val;
ui.lbl_output->setText(curVal);
}
However, I can see that this will not work due to the parameter, 'val'. Could someone please point me in the right direction? Thank you. I did look to see if this question had already been answered and couldn't find anything. If it has, please provide me a link.
Also, is it possible, using Qt Designer 4, to connect a widget to a custom slot?
Thank you.
As far as I know,Qt's signal/slot system requires that the number of parameters of signal function is not less than that of slots function.
In your example,the signal function click() have zero parameters and slot function writeNumberLbl("4") have one parameter,this will not be accepted by the Qt's signal/slot system and if you run your program in debug mode of Qt creator,the qDebug will show you a message like 'Incompatiable signal/slot' blalbalba~. To solve this problem, just read the article given by Arnold Spence. It is quite clear.
There are a number of ways to tackle this problem and they are outlined very nicely here. Although that page is a bit old, I think it is still quite valid. I would recommend using a signal mapper.
For your second question, yes. You can connect signals and slots using Qt Designer by setting the designer in "Edit Signals/Slots" mode. Once in this mode, for example, you can drag a connection line from a button to the form. A dialog will open up allowing you to choose the signal and slot to connect. If you haven't already implemented a slot in code, you can specify the name of a slot and then add the code for it afterward.
The number of parameters in Slot can not exit those in Signal? and pressed() has none. You have two choices (three, counting the dumb one):
Use QSignalMapper. Its help is self-explanatory.
Connect all your buttons to single slot. In it, find out what button has been pressed. QObject::sender() function helps.
There are even more ways, but more complicated.
How can I autocommit data from QTableWidget, that is in editing state, when I fire some command?
Assume, that there is some grid and data in it (editable thorough delegate that fires QComboBox editor). So, one starting to select option in combo, but do not finish editing, then hit some button, that executes action, that uses data from that combo, but new choise is not committed yet :\
How can I programmatically finish editing in table?
I mean some not strict 'loop all items and finish editing' way, that I consider as bad and ugly.
OOPS: worked too much, so, haven't realised, that there could be only one pending editor at time. Question is still here.
There is a protected slot named "commitData" in the tableWidget. You can inherit from tableWidget, then add your own public method (or slot) and send a signal (or simply call commitData method) from there.
There is one problem. You'll need to provide the editor object, but tableWidget gives you no way to get the pointer you need.
If you're using your own createEditor method, you can save the pointer to the editor somewhere, where your method can get it. It's a hack, but it's the only way i know.
The current editor does not seem to be accessible from outside of the view, but its content is committed when the current model index changes. So a simple way to force a commit seems to be to call
table->setCurrentIndex (QModelIndex ())
plus restoring your previous current index afterwards if the widget is not discarded yet.
This is quite an old question but it still came up quite high on Google so just in case anyone else needs the answer QTableView has a protected method
void currentChanged(const QModelIndex ¤t, const QModelIndex &previous)
which causes the data to be commited and QTableWidget is built on QTableView so that should still work. I found this info on the Qt Forum.