Trivial re-implementation of QCoreApplication::notify entails infinite loop

[guenthk]

I use Qt4.3.3 on Windows Vista. If I re-implement QCoreApplication::notify in my application class in the trivial way which just passes every event back to QCoreApplication::notify then an infinite loop occurs as soon as the event loop is entered. Using the Visual Studio debugger I could only figure out that lots of timer events would occur again and again.

Background: My application presents a QSplitter view and I need to know when one of the QSplitter children is activated in the sense that one of its nested children receives the keyboard focus. I had hoped to solve this by using notify to catch all mouse press events anywhere in the QSplitter children.

QWorkspace/QMdiArea supposedly must solve this same problem, to keep track of the currently "active" sub-window, but I couldn't find out so far how they achieve this.

[wysota]

Could you show us the reimplementation of notify()? And why do you want to reimplement notify() in the first place? You can apply an event filter on the application object or on the splitter (or its children).

[guenthk]

The trivial re-implementation of QCoreApplication::notify reads:

class MyApp : public QApplication {
...
bool notify (QObject *receiver,QEvent *evt );
...
}
 
bool MyApp ::notify (QObject *receiver,QEvent *evt ) {
  return QCoreApplication::notify(reveiver,evt);
}

class MyApp : public QApplication {
...
bool notify (QObject *receiver,QEvent *evt );
...
}

bool MyApp ::notify (QObject *receiver,QEvent *evt ) {
  return QCoreApplication::notify(reveiver,evt);
}

To copy to clipboard, switch view to plain text mode 

This entails a never-ending flood of timer events.

===============================================

Now I have found out that QWorkspace uses qFindChildren to get a (huge) list of *all* (recursively) nested child widgets of a QWorkspaceChild and establishes an event filter for *each* of these. In this way every click on any tiny input widget is recognized and activates the QWorkspaceChild.

This appears as a very inelegant solution of the problem, and the newer QMdiArea widget seems to use a different method, but which?

===============================================

Of what avail is it to install an event filter for the application object? Will I recognize in this way when a mouse click is performed anywhere in one of my QSplitter children? I'll have to try this out!

Many thanks for the time being!

[wysota]

Of what avail is it to install an event filter for the application object?

You would intercept every event that happens in your application before it reaches its destination.

[guenthk]

Now I have tested the event filter method for the application object, the QSplitter and the QSplitter children. Result: Not a single event has been caught by the event filter, except for two child events from an object for that I had not installed an event filter.

Now I'll test whether the same happens on Linux.

[wysota]

Can we see the code?

[guenthk]

You mean the event filter installation?:

MyMainFrame::MyMainFrame() : QMainWindow() {
...
  myApp->installEventFilter(this);
...
}
 
bool MyMainFrame::eventFilter(QObject *o, QEvent *e) {
  return false;
}

MyMainFrame::MyMainFrame() : QMainWindow() {
...
  myApp->installEventFilter(this);
...
}

bool MyMainFrame::eventFilter(QObject *o, QEvent *e) {
  return false;
}

To copy to clipboard, switch view to plain text mode 

The eventFilter function is never called except in those two cases where I hadn't installed an event filter for o. Rather strange! The same happens in SuSE-Linux 10.3/Qt4.3.3.

I am now about to install Qt4.3.4 on Vista, hoping that the problem will disappear in some wondrous way then.

[guenthk]

After I have installed Qt4.3.4 and rebuilt our whole application, the reimplementation of QCoreApplication::notify now works without problems on Vista.