[Solved] Are nested event filters allowed/recommended

andre

Volker, you are right of course that I could have referenced the source code. Thanks for doing this, and confirming my suspision that Qt won't do funny stuff such as adding the same object twice in the filter chain. Not sure if you can rely on this behaviour 100% in the future, as it is not documented and thus may change. Sure, not very likely, but still.

Perhaps we should wait for an answer from Dieter however to hear if I understood him correctly on what he was worried about and what he meant with "nested event filters".

goetz

I'm pretty sure they will not change that :-) In fact it's good programming style to be liberal in what you accept and pedantic in what you put out.

d.oberkofler

[quote author="Andre" date="1294652387"]Let me try to see if I got your question right. "nested" is a tricky concept, I think. It seems you are talking about what happens in this case:
@
class ObjectParent: public QObject {
objectParent(QObject* someWatchedObject, QObject* parent):
QObject(parent)
{
someWatchedObject->installEventFilter(this);
}
}

class ObjectChild: public ObjectParent {
objectChild(QObject* someWatchedObject, QObject* parent):
ObjectParent(someWatchedObject, parent)
{
someWatchedObject->installEventFilter(this);
}
}
@
[/quote]

This is exactly what I was referring to and the answer I've received are (as always) excellent!
The reason why I've asked this in the first place is actually less "abstract" then what it might seem.
I my use case the base class is part of a mostly static framework and the derived class will be instantiated by a user of the library. As described the intuitive way to install an event filter in the base class would not work as expected if the derived class is not aware of this implementation detail and this is what I wanted to prevent in the framework.

If I got it right, I would need to install an event filter to a stand-alone event filter object to get this solved in a transparent way like in the following example:

@
class objectParent;

class EventFilterParent: public QObject
{
public:
eventFilterParent(objectParent* parent): QObject(parent), itsParent(parent) {}
bool eventFilter(QObject* obj, QEvent* event)
{
return itsParent->event(obj, event);
}

private:
objectParent* itsParent;
}

class objectParent: public QObject
{
objectParent()
{
this->installEventFilter(new eventFilterParent(this));
}
bool eventFilter(QObject* obj, QEvent* event)
{
// do stuff
return ???;
}
}

class ObjectChild: public ObjectParent {
objectChild(QObject* someWatchedObject, QObject* parent):
ObjectParent(someWatchedObject, parent)
{
someWatchedObject->installEventFilter(this);
}
}
@

giesbert

Hi Dieter,

Why do you implement eventFilter in the objectParent class?
You install an event filter on your own with a helper that calls your eventFilter method?
Then you can just overwrite event(), that has the same effect.

The EventFilterParent class is totally not needed here.

From your example, you can remove the eventFilter stuff from the objectParent class and the complete EventFilterParent class.

andre

In principle, I think you are right (though your implementation lacks a bit). You could protect your eventFilter implementation by putting the actual event filter in a separate, private object in your class and either handle it there, or defer the handling again to a private method in the widget. Still, you have to ask yourself how useful that is. You run the risk that the user is unaware of the internals of your class not only with the eventFilter method, but with every virtual method in your widget, including those inherited from QObject and QWidget. And those are certainly not the -most- least important ones! When reimplementing a virtual method, you have to know what you're doing, and it often is a great idea to call the base implementation for the cases you don't handle yourself anyway. You have to ask yourself if you really want to try to protect the user of your library from all these possible pitfals?

goetz

The API docs on "QObject::eventFilter() ":http://doc.qt.nokia.com/stable/qobject.html#eventFilter even mentions this:

bq. Notice in the example above that unhandled events are passed to the base class's eventFilter() function, since the base class might have reimplemented eventFilter() for its own internal purposes.

You can add a prominent message in your API docs to warn your users.

Andre is totally right. It is good practice to call the base class' virtual method unless you really know what you're doing.

If you really want to, you can of course put the event filter in a private object of the parent class. If you do that, then there is no need to define and implement an eventFilter() method in the parent class.

giesbert

But the implemented filter was set on the parent class, where you don't need an event filter, as it always gets it's own events.
In the example code, the event filter object redirects the events from the object to itself.

goetz

Calling event() from eventFilter() seems quite dangerous to me (infinite recursion?).

I would go with Andre's first suggestion. It's clean and well understandable and supported. And it's what virtual functions are meant for :-)

giesbert

Volker, if you read the example code of Dieter, you see:

@
class CInternalFilterObject : public QObject
{
public:
CInternalFilterObject(CObjectToFilter* parent): QObject(parent), itsParent(parent) {}
bool eventFilter(QObject* obj, QEvent* event)
{
return itsParent->event(obj, event);
}

private:
CObjectToFilter* itsParent;
}

class CObjectToFilter: public QObject
{
CObjectToFilter()
{
installEventFilter(new CInternalFilterObject(this));
}
bool eventFilter(QObject* obj, QEvent* event)
{
// do stuff
return ???;
}
}
@

That means, in the class CObjectToFilter, he creates an object to filter the events of CObjectToFilter (CInternalFilterObject), which then calls CObjectToFilter. This is a loop from CObjectToFilter over CInternalFilterObject to CObjectToFilter. That means, it can also be removed and will have the same effect.

goetz

That solution is way to complicated! I don't even want to understand it!

One should go with Andre's first suggestion.
It works. It is simple. It is beautiful. It is like C++ was meant. Point.

giesbert

That's not my solution, that was the initial code by Dieter.

And as he redirected the events to himself, I said, he can juts leave the event filters out and overwrite event :-)

d.oberkofler

Thank you for all your valuable input.

I must admit that I did not even know of the option to just overload the method QObject::event()
This is an interesting alternative to the use of an event filter and would clearly make my second code snippet simpler.
For my specific problem I will stick with the good old "call the base class’ virtual method" approach as suggested.

@
bool derivedClass::eventFilter(QObjectobj, QEvent event)
{
if (event->type() == ...)
{
// do stuff ...
return ???;
}
else
{
// if it's not "ours", just pass the event on to our parent class
return parentClass::eventFilter(obj, event);
}
}
@

giesbert

[quote author="Dieter" date="1294754903"]

I must admit that I did not even know of the option to just overload the method QObject::event()
This is an interesting alternative to the use of an event filter and would clearly make my second code snippet simpler.
[/quote]

If you are only interested in some special events, you can also just overwrite the specific event handlers (see "QObject":http://doc.qt.nokia.com/latest/qobject.html#protected-functions and "QWidget":http://doc.qt.nokia.com/latest/qwidget.html#protected-functions documentation).

goetz

QObject::event() only works for the events that are actually delivered to the QObject where this method is (re)implemented.

QObject::eventFilter() is for one QObject that filters the events of another QObject. Although it can be abused on this object too (thus filtering events on itself), it would definitely be better to reimplement event() (or any of the specialized xyzEvent() methods) in this case! Please do everyone a favor and consider this!

Also, watch out to check the obj pointer in eventFilter()! You should react on the event type and the proper object!

d.oberkofler

Thank you for the additional clarifications!