How to generate an event to ESC (Escape), F1 and such keys.
-
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.
-
[replied in the embedded forum]
-
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.
-
[quote author="dfaure" date="1283803055"][replied in the embedded forum][/quote]
Lets continue here. The other thread is going to fall.
-
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]
-
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.
-
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.
-
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.
-
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)?
-
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.
-
I'll give a shot on Monday. Maybe we are lucky this time. Will post news asap.
-
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.
-
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.
-
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.
