Removing key bindings from QLineEdit
-
Unfortunately, that will completely "eat" the event, such that no other widgets get it either, right? I had to implement keyPressEvent() in my subclass such that most key presses got sent to QLineEdit, but the undo and redo got sent straight up to QWidget (and from their onto the parent widget and so on, until they finally make their way to the QAction assigned to them).
-
bq. Unfortunately, that will completely “eat” the event, such that no other widgets get it either, right? I had to implement keyPressEvent() in my subclass such that most key presses got sent to QLineEdit, but the undo and redo got sent straight up to QWidget (and from their onto the parent widget and so on, until they finally make their way to the QAction assigned to them).
That is not correct. You can and in most cases you should call the eventFilter from the base class. And the eventFilter has a return value. You have to return true or false otherwise you have undefined behavior. As example from the doc:
@bool MainWindow::eventFilter(QObject *obj, QEvent *event)
{
if (obj == textEdit) {
if (event->type() == QEvent::KeyPress) {
QKeyEvent keyEvent = static_cast<QKeyEvent>(event);
qDebug() << "Ate key press" << keyEvent->key();
return true;
} else {
return false;
}
} else {
// pass the event on to the parent class
return QMainWindow::eventFilter(obj, event);
}
}@ -
I must be misunderstanding the point: how does eventFilter() here differ from what I've done with keyPressEvent()? Either way I have to subclass QLineEdit and implement one or the other function, which both appear to achieve the same thing in more or less the same way, no?
-
bq. I must be misunderstanding the point: how does eventFilter() here differ from what I’ve done with keyPressEvent()? Either way I have to subclass QLineEdit and implement one or the other function, which both appear to achieve the same thing in more or less the same way, no?
The advantage of the eventFilter is that you don't have to subclass the QLineEdit. So you can use the standard widget and handle the desired behavior in the eventFilter and you can handle in one place different or same widget types and change behavior.
-
AH! Your'e right then, that's exactly what I want: I didn't understand that the eventFilter() was happening BEFORE the event made its way to the QLineEdit, I thought it was something I had to implement IN the QLineEdit. Awesome, thanks for the clarification.