Unregister timer error when deleting menu after qmenu::exec()
-
Sometimes when I use the construct
@void MyClass::contextMenuEvent(QContextMenuEvent *e)
{
QMenu *localMenu = new QMenu(this);QAction action=new QAction("SomeItem", this);
localMenu->addAction(action);
/ [ ... add more actions to the menu ... ] */localMenu->exec(e->globalPos());
delete localMenu;
}@to open a context menu. I get an error message like
Application asked to unregister timer 0x3e00000b which is not registered in this thread. Fix application.This does not happen all the time, and it's hard to pin-point what exactly triggers the problem, but it may look like the message appears more often if moving the mouse a lot while the menu is visible, perhaps also with the right button depressed. Closer inspection reveals that the problem is related to the use of QBasicTimer (presumably) internally in the widget code - it's more or less the same as what's described in
https://bugreports.qt-project.org/browse/QTBUG-16175This is with Qt 4.7.3 under Linux.
Has anyone else seen this? Is it a Qt bug? Is there a workaround? Do you think upgrading to a newer Qt version would help? Actually, I'm trying to build 4.8.1 right now, but it takes forever and a half to finish...
TIA
-
Uhhh, I just realised that a comment to the bug report actually mentions a possible patch for the qmenu implementation (although the report is originally about Qt development tools.) Didn't notice that earlier. So I suppose this is a problem with Qt, then. ..
-
According to the bug report is it fixed as of 4.7.4.
-
It was not entirely clear to me from reading the report whether the fix applied to the qmenu problem or just some other cases mentioned, but I now notice someone mentions that the warning itself has been removed (yeah, I should read more carefully the fist time around...)
Based on inspection of the source code, I suspect that the fundamental issue has not been resolved, though, i.e. qmenu still has timers that may be active after the menu is closed and exec() has returned, and that are potentially unregistered twice on destruction. I'll try not to let that bug me...