Preventing Enter key from triggering OK in QButtonBox in particular QLineEdit QButtonBox

andre

Why?

A line edit is not supposed to accept an Enter keypress, as it only displays one line of text. For a QTextEdit, this works of course.

aurorius

I may have misunderstood you, but a QLineEdit does accept Enter key when there's a QButtonBox in the Dialog. Of course, it doesn't put the Enter character in the field, but it triggered the accepted() slot for the QButtonBox, so does other widgets in the Dialog. It's like Enter is the default key for the Dialog that will trigger the accepted() slot.

I tried installing event like this:

@bool UrusBelianByStok::eventFilter(QObject *o, QEvent *e)
{
if (o == lineStok) {

    if (e->type() == QEvent::MouseButtonRelease) {
        openSelectStok();
    }
    else if (e->type() == QEvent::KeyPress) {

        QKeyEvent* keyEvent = static_cast<QKeyEvent*>(e);

        if (keyEvent->key() == Qt::Key_Return) {
            qDebug() << "ATE";
            e->ignore();
            return false;
        } else {
            qDebug() << "MISSED";
        }
    }
}

return QWidget::eventFilter(o, e);

} @

lineStok = QLineEdit,

but it still accept the Enter key.

dangelog

[quote author="aurorius" date="1302685179"]I have a Dialog which has some widgets such as QComboBox, QSpinBox and some QLineEdit. At the bottom of the widget, I have a QButtonBox. Clicking enter in any one of the widgets will trigger the accepted() slot for the QButtonBox. However, I'd like to disable this automated action in one of the QLineEdits. So, pressing Enter key in one of the QLineEdit wouldn't trigger the accepted() slot for the QButtonBox. How can I do that?[/quote]

Pressing Enter inside a dialog will automatically trigger the default pushbutton.

The logic is inside QDialog::keyPressEvent
https://qt.gitorious.org/qt/qt/blobs/master/src/gui/dialogs/qdialog.cpp#line674

Therefore, override it that and don't call the base class implementation, or install an event filter on it and filter out that event.

andre

Yes, I think we misunderstand each other.

QLineEdit does not accept the Enter key. That is why the key event is passed up to the QDialog to handle, which in turn uses it, as you guessed, as the default key to signify an acceptance.

Your idea to use an event filter is a good one. I assume you installed it properly?
However, your idea of what QEvent::ignore does, is off. You should accept the event if you want to eat it, not ignore it. Also, you need to take care of this piece of information from the documentation of eventFilter:
[quote]
In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.
[/quote]

That is: you are telling Qt in all possible ways now that you do want Qt to continue handing your key press event, instead of eating it.

goetz

One can disable this behavior by setting setDefault() and setAutoDefault() on the button. To disable this on all buttons in your dialog add this snippet after you instantiated and initialized the ui from Designer:

@
QList<QPushButton *> buttonList = findChildren<QPushButton *>();
foreach(QPushButton *pb, buttonList) {
pb->setDefault( false );
pb->setAutoDefault( false );
}
@

aurorius

[quote author="peppe" date="1302687735"]
[quote author="aurorius" date="1302685179"]I have a Dialog which has some widgets such as QComboBox, QSpinBox and some QLineEdit. At the bottom of the widget, I have a QButtonBox. Clicking enter in any one of the widgets will trigger the accepted() slot for the QButtonBox. However, I'd like to disable this automated action in one of the QLineEdits. So, pressing Enter key in one of the QLineEdit wouldn't trigger the accepted() slot for the QButtonBox. How can I do that?[/quote]

Pressing Enter inside a dialog will automatically trigger the default pushbutton.

The logic is inside QDialog::keyPressEvent
https://qt.gitorious.org/qt/qt/blobs/master/src/gui/dialogs/qdialog.cpp#line674

Therefore, override it that and don't call the base class implementation, or install an event filter on it and filter out that event.[/quote]

[quote author="Volker" date="1302688920"]One can disable this behavior by setting setDefault() and setAutoDefault() on the button. To disable this on all buttons in your dialog add this snippet after you instantiated and initialized the ui from Designer:

@
QList<QPushButton *> buttonList = findChildren<QPushButton *>();
foreach(QPushButton *pb, buttonList) {
pb->setDefault( false );
pb->setAutoDefault( false );
}
@
[/quote]

[quote author="Andre" date="1302687820"]Yes, I think we misunderstand each other.

QLineEdit does not accept the Enter key. That is why the key event is passed up to the QDialog to handle, which in turn uses it, as you guessed, as the default key to signify an acceptance.

Your idea to use an event filter is a good one. I assume you installed it properly?
However, your idea of what QEvent::ignore does, is off. You should accept the event if you want to eat it, not ignore it. Also, you need to take care of this piece of information from the documentation of eventFilter:
[quote]
In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.
[/quote]

That is: you are telling Qt in all possible ways now that you do want Qt to continue handing your key press event, instead of eating it.

[/quote]

Thanks a lot for all of the suggestions. In the end, I managed to solve it by returning true from the eventFilter, just like what Andre said.

tempest766

<ENTER> in a lineedit, causing the triggering of a pushbutton that does not have the current focus, should be considered a QT bug, not a feature.

andre

[quote author="tempest766" date="1329288514"]<ENTER> in a lineedit, causing the triggering of a pushbutton that does not have the current focus, should be considered a QT bug, not a feature.

[/quote]
Why are you digging up an almost one year old topic just to post a nonsense statement like this?

tempest766

because the "workarounds" are just that, hackish workarounds for a situation that shouldn't exist to begin with. implicit triggering of events in sibling widgets is questionable design. Any triggering of sibling widgets should be caused by EXPLICT connections set up by the programmer, not as a result of "mystic" toolkit semantics.

That and I ran into this issue tonight while trying to implement a popup dialog with limited space and needing to use <ENTER> or "enterPressed()" to trigger updates on the dialog itself. IMHO there is really little excuse for the <ENTER> triggering subsequent pushbuttons when the linedit clearly had focus.

andre

The Windows UI styleguide, to name just one, disagrees. The Enter key is "supposed":http://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_fundamentals_of_keyboard_ui_design to trigger the default action of a dialog.

I'm sure similar rules apply to OS-X, KDE and Gnome.

You may think it is a bad idea, but I think it is a bad idea to break UI standards. And the standard is to trigger to default action.