Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Removing key bindings from QLineEdit
Forum Updated to NodeBB v4.3 + New Features

Removing key bindings from QLineEdit

Scheduled Pinned Locked Moved General and Desktop
9 Posts 4 Posters 4.8k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    Chris H
    wrote on last edited by
    #1

    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?

    1 Reply Last reply
    1
    • P Offline
      P Offline
      p-himik
      wrote on last edited by
      #2

      I think you can try redefining of keyPressEvent().

      1 Reply Last reply
      0
      • C Offline
        C Offline
        Chris H
        wrote on last edited by
        #3

        Yeah, that's the only way I could figure out to do it. I was hoping there was a function I was missing. Thanks.

        1 Reply Last reply
        0
        • G Offline
          G Offline
          goetz
          wrote on last edited by
          #4

          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.

          http://www.catb.org/~esr/faqs/smart-questions.html

          1 Reply Last reply
          0
          • C Offline
            C Offline
            Chris H
            wrote on last edited by
            #5

            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).

            1 Reply Last reply
            0
            • S Offline
              S Offline
              Scylla
              wrote on last edited by
              #6

              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);
              }
              }@

              1 Reply Last reply
              1
              • C Offline
                C Offline
                Chris H
                wrote on last edited by
                #7

                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?

                1 Reply Last reply
                0
                • S Offline
                  S Offline
                  Scylla
                  wrote on last edited by
                  #8

                  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.

                  1 Reply Last reply
                  0
                  • C Offline
                    C Offline
                    Chris H
                    wrote on last edited by
                    #9

                    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.

                    1 Reply Last reply
                    0

                    • Login

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved