Derived Class for QScrollArea Concerning Keypad Navigation on Embedded Linux Platform

[cloaked_and_coastin]

I got a question.

Here's a long story short:

We started on a project for an Embedded Linux platform. This platform does not have a mouse or keyboard. It just has a keypad 0-9, Up, Down, Left, Right, Enter and Cancel buttons.

Using Qt 4.7.0, we couldn't figure out why keypad navigation wouldn't work with the Arrow keys (I believe it was the Up/Down keys that were not working).

We then discovered the magic of grabkeyboard() and releasekeyboard(). It was at this point that Pandora's box was opened.

So these calls got spread throughout the build, what a headache. Now after doing some thinking/research, I'm going back and cleaning this up.

As I understand it today, without the grabkeyboard() and releasekeyboard() calls in a build, Qt will deliever QKeyEvent(s) to a widget that has focus.

Now one of our screens within our application may be a parent widget, but a QKeyEvent will get delivered to a child widget FIRST before the parent widget.

Some QWidget(s) may filter or consume out certain QKeyEvent(s) by design (not sure why). For QKeyEvent(s) that are delivered to a child widget that are NOT consumed by design get passed onto the parent widget if it hits a:

QWidget::keyPressEvent(ptr_to_QKeyEvent) method call.

From what I gather, its a matter of understanding the parent/child relationship or parent/child chain which can have multiple levels.

OK, given the story and an explanation of my ***understanding*** above, I've dervied some qwidget classes that override the keyPressEvent to not filter
out some QKeyEvent(s) (Qt::Key_Up and Qt::Key_Down), but to pass it onto the parent.

My question:

If I have a derived class for a QScrollArea, that has an empty constructor and a very limited switch statement within the keyPressEvent as such:


void myScrollArea::keyPressEvent(QKeyEvent *e)
{
switch(e->key())
{
case Qt::Key_Up:
case Qt::Key_Down:
QScrollArea::keyPressEvent(e);
QWidget::keyPressEvent(e);
break;

default:
QScrollArea::keyPressEvent(e);
break;
}
}

Is it OK to have two method calls for the Qt::Key_Up and Qt::Key_Down keys? The QScrollArea::keyPressEvent(e) call is to maintain the natural behavior for the class. The QWidget::keyPressEvent(e) call is so the the Up/Down keys are not filtered out by myScollArea, but gets passed onto its parent.

I'm concerned that both method calls may try to delete the pointer at some point. All my testing seems to be going OK though.

Just being cautious.

Thanks for your patience and any help for answering this question.

[amleto]

why aren't you using eventfilter instead? Seems like that is what you are trying to do.

I would think events would only be deleted from the main loop so it wont matter how many parent class implementations you call.