[SOLVED] QLineEdit::keyPressEvent() ignores Qt::Key_Escape (keyReleaseEvent works)
-
Hi again :)
I am trying to catch the escape key to trigger the cancellation when editing QLineEdits. I've subclassed and at the current moment the thing is simple enough:
[code]
myLineEdit::myLineEdit(QWidget *parent) :
QLineEdit(parent)
{
}void myLineEdit::keyPressEvent(QKeyEvent *e)
{
qDebug() << Q_FUNC_INFO;
switch(e->key())
{
case Qt::Key_Escape:
qDebug() << Q_FUNC_INFO;
emit escapeKeyPressed();
default:
QLineEdit::keyPressEvent(e);
}
}[/code]I know it's working because while I am editing, I can see the qDebug() speech flowing, but if I press ESC it doesn't print anything. So, I assume that it's either ignoring ESC or that something else (maybe the main window?) is catching it before it gets to myLineEdit();
Any idea?
Thanks :)
-
If your standard keys get through, there is no reason why the ESC key shouldn't. Did you try to reimplement keyReleaseEvent() to find out if it has problems with the ESC key? Maybe it is one of these strange keys that only trigger on their release.
-
So keyReleaseEvent() works... Is there any standard way to deal with this in Qt? I mean, is this behaviour keyboard dependent? If so, how can I be sure that this will work ok no matter what keyboard I am using?
-
It might be hardware-dependent or even OS-dependent. But I think you can rely on the keyReleaseEvent being triggered, since neither hardware nor OS should be ok with "stuck" (only keyPress registered, nothing after) or plain non-working (neither keyPress nor keyRelease triggered) keys.
This behavior I only ever noticed with things like Ctrl, ESC and such, not the "usual" keys - if you want to find out more, read up on keyboards or wait for somebody with a bigger brain than mine to enlighten you. :) -
[quote author="thEClaw" date="1378364077"]It might be hardware-dependent or even OS-dependent. But I think you can rely on the keyReleaseEvent being triggered, since neither hardware nor OS should be ok with "stuck" (only keyPress registered, nothing after) or plain non-working (neither keyPress nor keyRelease triggered) keys.
This behavior I only ever noticed with things like Ctrl, ESC and such, not the "usual" keys - if you want to find out more, read up on keyboards or wait for somebody with a bigger brain than mine to enlighten you. :)[/quote]Now that you mention it, I remember having to deal with similar stories in the past, and I am talking about QBASIC and DJGPP so it was back in DOS times.
I never bothered to investigate on this.
Well, thank you for all the info. It's been useful :)