Removing window from QWorkspace

[brcain]

Short version ...

I need to prevent Qt from deleting a window that was added to a QWorkspace via QWorkspace::addWindow().

Long version ...


class cPlatView : public QDialog, public Ui::cPlatView, public cView
{
// ...
};

// ...
boost::shared_ptr<cPlatView> somePlatView;

// ...
mMainWindow->addView(somePlatView.get());



I'm using an MVC architecture where the controller manages the lifecycle of the model and the view (view being a window in the instance). The controller code (a non-Qt library) uses Boost::shared_ptr to manage memory of the model and view instances. Since the Qt addWindow call handles a naked pointer (retreived from controller by dereferencing Boost::shared pointer), Boost doesn't know that Qt has a reference to the view. So, during shutdown, the view is deleted twice ... once by Boost::shared_ptr and once by Qt.

To prevent double-delete ... how do I tell Qt not to delete memory for the view? Do I remove the window for the QWorkspace? Or do I call view::setParent(0)?

[wysota]

The easiest way is to just increment the reference count on the pointer so that boost doesn't auto-delete it. You can't remove the parent pointer from the object, because the workspace would probably lose control over the window, you can try by removing the window from QWorkspace and then clearing the parent (although I don't know if such thing as "removing from workspace" exists at all - you'd have to remove the view object from workspace child window by reparenting the view, then delete the workspace child and hope that everything else works). But surely incrementing the reference count is the proper solution :)

[brcain]

I didn't increment the boost::shared_ptr. However, your suggestion got me thinking. I decided to use the Bridge pattern to separate the MVC's view and the Qt's view. It was the permanent binding (via inheriting from cView) that was causing the problem.

Now the view bridge handles the memory management issues between Qt and Boost. Inheritance isn't always evil as some claim, but it was in this case. :eek:

Thanks for you input.