0

As the title says, what is this thing and how do I handle it?

It's a QObject and asks for a QObject as it's parent. But at the same time it has child objects that are clearly QWidgets.

Typically with QObjects, you can either let the parent delete it when the parent is deleted, or you can delete it yourself. But QSystemTrayIcon doesn't seem to work this way - I've tried making it the child of an arbitrary QObject and then letting it's parent delete it - when I do this, a lingering event gets sent to the QSystemTrayIcon that's been parent-deleted. On OSX this segfaults because it ends up sending an obj message to an invalid object.

This might be because the QMainWindow is going away at the same time in my application.

If I have to delete it explicitly after un-childing it, why? And if that's the case, it sounds like this is timing-dependent or something.

If QSystemTrayIcon really just wants a QWidget as its parent, why isn't its constructor written that way?

Ted Middleton
  • 6,859
  • 10
  • 51
  • 71
  • Did you try using `deleteLater()` instead of `delete`? That should help make sure that all the appropriate events are delivered before the `QSystemTrayIcon` is deleted. – deGoot May 09 '14 at 03:21

2 Answers2

0

The following approach works:

  • Subclass QApplication
  • Make QSystemTrayIcon instance to be child of app instance, if you want
  • Create custom app destructor which deletes tray first

Tray internally uses QWidget, and its deletion works incorrectly when QApplication instance already destroyed.

Sergey Shambir
  • 1,562
  • 12
  • 12
0

that's all

trayIcon->setVisible(false);
exit(0);
Artur Kwiek
  • 1
  • While this code may answer the question, providing additional context regarding why and/or how this code answers the question improves its long-term value. – Al Foиce ѫ Jul 09 '21 at 08:26