Removing key bindings from QLineEdit
-
The documentation for QLineEdit lists out all of the "default key bindings" that it grabs. I'd like to disable some of them (in particular undo and redo, which are now handled outside the widget): how do I do this?
-
I think you can try redefining of keyPressEvent().
-
Yeah, that's the only way I could figure out to do it. I was hoping there was a function I was missing. Thanks.
-
You should be able to "eat" the keypress event in an eventFilter too. The Docs for the "QObject::eventFilter() ":/doc/qt-4.8/qobject.html#id-a6121c3f-c93c-4f3c-8158-ed7e4d0d77f2 method even has an example that demonstrates your very use case.
-
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.