using QKeyEvents

[mzimmers]

@gde23 I guess I don't understand the reason for the subclass. I want to trap a key press anywhere on my main widget. I don't want sub-class my main widget, do I?

[SGaist]

Hi,

It's the other way around, you need to install KeyPress in your QMainWindow.

[mzimmers]

@SGaist not using QMainWindow; using QWidget.

class Widget : public QWidget
{
    Q_OBJECT
...

Same thing, though?

And by "install KeyPress" I assume you mean more than create an object of that class, since I'm already doing that.

    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    m_keyPress->installEventFilter(this);

I'm missing a step here, aren't I?

[SGaist]

You're not missing a step, you are doing one in the wrong direction. The object on the left of installEventFilter is the one that is going to be monitored so just call

installEventFilter(m_keyPress);

See the installEventFilter documentation.

[mzimmers]

OK...made that change; still not seeing what I expect.

    // create and connect a KeyPress object.
    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    installEventFilter(m_keyPress);

Here's my event routine:

void KeyPress::keyPressEvent(QKeyEvent *ev)
{
    int key;

    key = ev->key();
    if (key == Qt::Key_Alt)
    {
        emit keyEvent(QEvent::KeyPress, key);
    }
}

I'm never hitting a breakpoint in there.

[SGaist]

Because an event filter re-implements the eventFilter method and does all there. It does not replace a class original methods.

[mzimmers]

@SGaist said in using QKeyEvents:

Because an event filter re-implements the eventFilter method and does all there. It does not replace a class original methods.

So, which object needs the eventFilter() method? I've tried adding to both the Widget and the KeyPress -- both compile and run, but neither trigger a breakpoint.

[SGaist]

Did you check the example I linked to ?

[mzimmers]

@SGaist you're referring to the KeyPressEater class in the QObject::installEventFilter() documentation, right?

Its behavior isn't the same as my KeyPress class, but I can worry about that later. I still don't see why I'm not hitting a breakpoint.

bool KeyPress::eventFilter(QObject *obj, QEvent *ev)
{
    bool rc = false;

    if (ev->type() == QEvent::KeyPress)
    {
        if (obj == this)
        {
            rc = true;
            qDebug() << ev;
        }
    }
    return rc;
}

My breakpoint is on my inner "if" and it's never reached.

[SGaist]

Because as is, your filter will never be the target of a KeyPress event.
The value of obj will be one of the object you installed your filter on.

[mzimmers]

I understand your 2nd statement, but not the first. I install the filter on my Widget object. Is a QWidget incapable of accepting KeyPress events?

[mzimmers]

Well, I got it partly working -- the problem was that I was deriving my KeyPress class from QWidget instead of QObject.

Now, though, my filter only seems to be trapping "meta keys." Control, alt, etc. all work, but regular keys like A, B, C don't. It appears that these keys generate a ShortcutOverride event. Does this make sense to you?

Thanks...

[mzimmers]

My filter seems to be doing what I want (when two keys are held down, I make a button visible).

    if (C_pressed && D_pressed)
    {
        ui->pushButtonNics->setVisible(true);
    }
    else
    {
        ui->pushButtonNics->setVisible(false);
    }

But when I click on that button, my clicked slot isn't reached. I thought maybe holding down the keys was blocking the button push, but my other buttons work fine. My button is enabled when visible (I checked in the debugger). Any ideas why it's not generating the signal?

Thanks...

[SGaist]

You are forgetting to call the base class implementation.

[mzimmers]

@SGaist I hadn't forgotten; I just hadn't gotten to that yet. But shouldn't I hit this slot anyway?

void Widget::on_pushButtonNics_clicked()
{
    qDebug() << "Nics pressed.";
}

[SGaist]

The last implementation I saw does not call it at all which means that all events are filtered out.

To check, comment out the filter installation and see if it does work correctly.

[mzimmers]

@SGaist let's make sure we're talking about the same thing. Here's where I create the filter:

    // create and connect a KeyPress object.
    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    installEventFilter(m_keyPress);

    // hide the button for the NICs window.
//    ui->pushButtonNics->setVisible(false);

You'll notice that the last line is commented out. And, it works. So it would seem that it has something to do with the filter...?

[SGaist]

Can you provide a minimal compilable example that shows the behaviour ?
Si au can check on my side what is going on.

[mzimmers]

@SGaist

keypress.h

#ifndef KEYPRESS_H
#define KEYPRESS_H

#include <QWidget>
#include <QtGui>

class KeyPress : public QObject
{
    Q_OBJECT
public:
    explicit KeyPress(QWidget *parent = nullptr);
protected:
    bool eventFilter(QObject *obj, QEvent *ev) override;

signals:
    void keyEvent(QEvent event, int key);
};

#endif // KEYPRESS_H

keypress.cpp

#include "keypress.h"

KeyPress::KeyPress(QWidget *parent) : QObject (parent)
{
}

bool KeyPress::eventFilter(QObject *obj, QEvent *ev)
{
    Q_UNUSED(obj)

    bool rc = false;
    int key;
    QKeyEvent *qke;

    if (ev->type() == QEvent::ShortcutOverride || ev->type() == QEvent::KeyRelease)
    {
        qke = static_cast<QKeyEvent *>(ev);
        key = qke->key();

        // don't bother signaling when the key isn't meaningful to us.
        if (key == 'c' || key == 'C' || key == 'd' || key == 'D')
        {
            emit keyEvent(*ev, key);
        }
        rc = true;
    }
    else
    {
        rc = QObject::eventFilter(obj, ev);
    }
    return rc;
}

Let me know if there's something more you want to look at...thanks.

[SGaist]

A minimal widget that you install that filter on would be nice :-)