App crashes when moving a DockWidget outside MainWindow

[franku]

Hi There, I have got an application that always crashes when having moved a dockwidget outside the mainwindow. When I leave the dockwidget at its iriginal Place on the left docking area the application will close fine.


App ist build up with this code (Control will instantiate and destroy mainwindow):


int main(int argc, char *argv[])
{
QApplication app(argc, argv);

// app will destroy Control
// because it becomes Control's
// parent object via constructur
Control::getSingleton(&app);
int ret = app.exec();

return ret;
} // app Object will be destroyed (and its children)


IMHO the ~Control() Destructor will be called by the Application at last, so when finishing the application there will be (the destr. ist definitively called):




/* singleton-private Constructor */
Control::Control(QObject *parent) :
QObject(parent),
{
...
if(!mainWindow)
mainWindow = new MainWindow();
...
}

Control::~Control()
{
...
if(mainWindow) {
delete mainWindow; // will delete the ui including dockwidgets
mainWindow = NULL;
}
}


The Problem now is that when I have App destroying the mainwindow there comes a segmentation fault along - ending always in qwidget.cpp...



....
else if (!internalWinId() && isVisible()) {
qApp->d_func()->sendSyntheticEnterLeave(this);
....


...where the d_func() with its scoped pointer will fail.

But: This only happens, when I have moved the DockWidet "Floating" away from its orignial Place in the main window. If I leave it there, everthing is ok.

As someone may see the stacktrace shows that the Dockwidget will make use of the qapplication d_func(). Am I wrong, or why do at least two parents try to delete the Widget (Mainwindow and App) ?


0 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::data qscopedpointer.h 135 0x00ff01e6
1 qGetPtrHelper<QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > > qglobal.h 2314 0x008a63ff
2 QApplication::d_func qapplication.h 376 0x00eef9c4
3 ~QWidget qwidget.cpp 1438 0x008ec5f8
4 ~QDockWidget qdockwidget.cpp 1181 0x00c51fce
5 QObjectPrivate::deleteChildren qobject.cpp 1978 0x6a20f1b0
6 ~QWidget qwidget.cpp 1476 0x008ec6dc
7 ~QMainWindow qmainwindow.cpp 329 0x00c82888
8 ~MainWindow mainwindow.cpp 50 0x004018c0
9 ~Control control.cpp 83 0x00408feb
10 QObjectPrivate::deleteChildren qobject.cpp 1978 0x6a20f1b0
11 ~QObject qobject.cpp 975 0x6a20d0f9
12 ~QCoreApplication qcoreapplication.cpp 642 0x6a1fd127
13 ~QApplication qapplication.cpp 1118 0x008aa05e
14 qMain main.cpp 14 0x00401400
15 WinMain@16 qtmain_win.cpp 131 0x0040e612
16 main 0 0x0040e338


Any Comments ?

[alexisdm]

It seems MainWindow has already been destroyed by qApp when Control destructor is called (because MainWindow is a top-level window, qApp destroys it when it quits).

Instead of that manual delete, you can set your Control object as MainWindow parent, it will be deleted or removed from Control children if qApp get to it first.
And/or you can use a QPointer<MainWindow> instead of MainWindow* for Control::mainWindow, which would be set to 0 if MainWindow is deleted by qApp.

[franku]

Good Idea, this works fine if I derive my Control Class from QWidget and have a widget Object in the main() routine which will destroy everything as the parent of all. Formerly it Control was a QObject so I can't set it as the QWidget Parent of MainWindow. Although my ideas might appear somewhat academic thank you for your reply.

Is there a way to have a QObject-derived class as the parent of QMainWindow I do not understand so far.

Regards, .. frank

[alexisdm]

Is there a way to have a QObject-derived class as the parent of QMainWindow I do not understand so far.No, there isn't. There is a Q_ASSERT in setParent to prevent that.

But since Control and QApplication are both singletons, and QApplication already controls the lifetime of mainWindow, you could simply let Control inherit from QApplication.

[franku]

Ahh, you are right! This works well now. Though I am deleting the mainwindow still myself. Control is now the application .. yes ok. Thank you.