Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct


    Qt World Summit: Early-Bird Tickets

    How to generate an event to ESC (Escape), F1 and such keys.

    General and Desktop
    3
    14
    15239
    Loading More Posts
    • 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.
    • M
      marcus_cps last edited by

      Hi,

      Is there any way a class can generate an keyEvent indicating ESC key (or F1, or any other "special" key) is pressed, so the currently focused windows/widget can receive it?

      For instance: A class that receives key codes through a socket, and generate keyEvents. Something like a remove keyboard in the network.

      I did part of it, however, it works only for "regular" keys... I described the problem in more details in the Embedded forum. Here is the topic:

      ---- TOPIC REMOVED. Read bellow for further details.

      If anyone can help me with that, I'd appreciate very much.

      Thanks.

      1 Reply Last reply Reply Quote 0
      • D
        dfaure last edited by

        [replied in the embedded forum]

        David Faure (david.faure@kdab.com)
        KDE/Qt Senior Software Engineer
        KDAB - Qt Experts - Platform-independent software solutions

        1 Reply Last reply Reply Quote 0
        • M
          marcus_cps last edited by

          I agreed to the admin that I should keep only one post. So I'm adding more details here:

          I’m working on an embedded software in QT that uses LIRC to handle RC (Remote Control) key presses.

          I managed to map all the RC keys so directFB is getting keypresses like these:
          @00000000000011b7 00 MENU
          00000000000011a7 00 EXIT
          0000000000001193 00 RED
          @

          I’ve created a QT class (QObject public inheritance) that uses sockets to grab LIRC keys and generate KeyPressEvents through QApplication::postEvent for all the other QT widgets and alike.
          It works fine for “regular” keys, but it is not working for keys that emulate the ESC, F1, F2 and other “special” keys.

          I could make it work using signals and slots (check it bellow), however, it’s a harsh since I need to connect and disconnect the signals for active Windows (Widgets) all the time using showEvent and hideEvent. I refuse to believe there is no better solution for that.

          Does anyone know how to generate events for those special keys?

          Following a code snippet of the LIRC socket handler method:

          @QKeyEvent *event = NULL;
          int emitKey = 0;

          if (strstr(code, "MENU"))
          {
          cout << "MENU";
          event = new QKeyEvent(QEvent::KeyPress, Qt::Key_Menu, Qt::NoModifier, "Menu", 0);
          emitKey = Qt::Key_Menu;
          }
          else if (strstr(code, "EXIT"))
          {
          cout << "EXIT";
          event = new QKeyEvent(QEvent::KeyPress, Qt::Key_Escape, Qt::NoModifier, "Exit", 0);
          emitKey = Qt::Key_Escape;
          }
          else if (strstr(code, "RED"))
          {
          cout << "RED";
          event = new QKeyEvent(QEvent::KeyPress, Qt::Key_F1, Qt::NoModifier, "Red", 0);
          emitKey = Qt::Key_F1;
          }

          // All other keys, including regular keys and other special keys...

          if (event)
          {
          cout << ": POSTED!" << endl;
          event->ignore();
          QApplication::postEvent(this, event);
          emit k_output(emitKey);
          }
          @

          All the keys are getting detected, so I get the following debug output:
          @GREEN: POSTED!
          RED: POSTED!
          MENU: POSTED!
          @

          The Menu key event is reaching the active window’s keyEvent method. The others (EXIT, RED) are not…

          Thanks very much for your help.

          1 Reply Last reply Reply Quote 0
          • M
            marcus_cps last edited by

            [quote author="dfaure" date="1283803055"][replied in the embedded forum][/quote]

            Lets continue here. The other thread is going to fall.

            1 Reply Last reply Reply Quote 0
            • M
              marcus_cps last edited by

              Here is dfaure message that was posted in the other thread:

              [quote] At first sight I don’t see anything wrong with the code you posted, the problem must be elsewhere. What type of widget is “this”?
              One idea could it be that the Esc key closes the dialog, and that F1 triggers some help action…

              In fact between posting a QKeyEvent and getting a keyEventPressed, many things can happen:

              • shortcut handling (if a widget accepts the ShortcutOverride event for instance; or if a QAction exists with this key)
              • event filters

              Please give more information. Ideally extracting a standalone testcase, that’s the easier to look at smile. [/quote]

              [cleaned up formatting and deleted the other thread = Alexandra]

              1 Reply Last reply Reply Quote 0
              • M
                marcus_cps last edited by

                The handler from LIRC (Linux InfraRed client or something like this) is a QObject derived class.

                All the other windows are QWidgets and I'm trying to receive Keypress events in them.

                I'm doind a few test on monday. Now I'm in a holliday! :D
                Thanks. I'll be in touch.

                1 Reply Last reply Reply Quote 0
                • K
                  kkrzewniak last edited by

                  Am I getting something wrong here or is your “key interpreting” object posting events to itself.
                  @void QCoreApplication::postEvent ( QObject * receiver, QEvent * event )@
                  If that is the case than I think You should check this objects keyPressEvent, maybe those specific events get accepted by this object and their propagation stops there.

                  Me, Grimlock, not "nice dino". ME BASH BRAINS!

                  1 Reply Last reply Reply Quote 0
                  • M
                    marcus_cps last edited by

                    This class is something like a keyboard driver, however not to a keyboard, it is to the IR Remote Control.
                    It recieves the Remote Control keypress through a socket. And that code would translate the string information about the pressed key to a QT key event.
                    My goal is to use this class to generate key events to the entire application.

                    Notice that I'm generating QKeyEvents and using a signal to notify any registered slot about that too.
                    That's an workaround, I really want to take this signal/slots approach out and keep using the QKeyEvent part only.

                    I believe this is how I generate key events to the entire application, so the QT framework itself decides which Widget is going to receive the event.

                    @
                    void QCoreApplication::postEvent ( QObject * receiver, QEvent * event )
                    @

                    Is this wrong?
                    Maybe we've found the mistake.

                    1 Reply Last reply Reply Quote 0
                    • M
                      marcus_cps last edited by

                      Maybe I'm wrong!
                      Now I noticed the first parameter is the RECEIVER of the Event, not the GENERATOR of the event.
                      Have to read a little about that.
                      Does anyone know something about how to generate events to the entire application (letting QT decide who is going to receive the event)?

                      1 Reply Last reply Reply Quote 0
                      • K
                        kkrzewniak last edited by

                        Just a wild guess but I would try using @QApplication::postEvent(qApp, event);@ instead of @QApplication::postEvent(this, event);@ as qApp is a pointer to the object representing the current QApplication instance. But I don't relay know if that'll result in the event being passed to the active widget I don't know.

                        Me, Grimlock, not "nice dino". ME BASH BRAINS!

                        1 Reply Last reply Reply Quote 0
                        • M
                          marcus_cps last edited by

                          I'll give a shot on Monday. Maybe we are lucky this time. Will post news asap.

                          1 Reply Last reply Reply Quote 0
                          • D
                            dfaure last edited by

                            kkrzewniak: posting events to qApp will only post the event to qApp, not to the active widget ;)

                            If one wants to send events to the active widget, then sending them to QApplication::focusWidget() might help.

                            David Faure (david.faure@kdab.com)
                            KDE/Qt Senior Software Engineer
                            KDAB - Qt Experts - Platform-independent software solutions

                            1 Reply Last reply Reply Quote 0
                            • M
                              marcus_cps last edited by

                              Great idea.
                              I've been trying to find some time to test the last suggestion kkrzewniak made.
                              I'll do it ASAP and will try this too.
                              It sounds like will work.

                              Thanks very much for your help.

                              1 Reply Last reply Reply Quote 0
                              • M
                                marcus_cps last edited by

                                That worked.

                                I had to make a lot of changes to fit with this.
                                But now, that's all fine!

                                Thanks so much for your help guys.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post