Hello All,
Chris wrote:
> Julie,
> I left Michael's code where it was. Everything fires ok
> (including the
> destructor) and the closeevent seems the logical place to
> put it
> (actually, in my mind a bit better than the destructor).
> Regards
> Chris
Okay. If you like .
But here is the real culprit.
NotationTool::~NotationTool()
{
NOTATION_DEBUG << "NotationTool::~NotationTool()" << endl;
delete m_menu;
}
NotationTool does not own m_menu
BaseTool does.
Bur baseTool relys on FileActionClient to delete it.
so
NotationTool::~NotationTool()
{
NOTATION_DEBUG << "NotationTool::~NotationTool()" << endl;
delete m_menu;
}
fixes it on my machine. But I still need to reevert the other changes I made
and try this fix solo to see if it works.
Sincerely,
Julie S.
--- On Thu, 9/3/09, Chris Fryer <[email protected]> wrote:
> From: Chris Fryer <[email protected]>
> Subject: Re: [Rosegarden-devel] NotationView crash on close was Re: oh, and
> To: "Julie S" <[email protected]>
> Date: Thursday, September 3, 2009, 10:48 AM
> Julie,
> I left Michael's code where it was. Everything fires ok
> (including the
> destructor) and the closeevent seems the logical place to
> put it
> (actually, in my mind a bit better than the destructor).
> Regards
> Chris
>
> On Thu, Sep 3, 2009 at 3:43 PM, Julie S<[email protected]>
> wrote:
> > Hello All:
> >
> > I've been playing around with this bug and have made
> some progress.
> >
> > The bug appears to have a few levels, some of which
> I've untangled.
> >
> > NOTE: Not pointing fingers, but only explaining.
> >
> > This in some form may have existed before Michael
> included saving screen geometry, but that has added a layer
> to untangle.
> >
> > The geometry save routine was placed in the
> closeEvent() methods that over ride the default handler.
> >
> > I assume this was done since the de-constructor was
> not being called because QT was "hiding" the widgets (views)
> and not really deleting them.
> >
> > This much I have sorted.
> >
> > After fixing that, the chain of calls on close are
> more logical. Before the parent classes were not allowed
> to handle the event nor and things were getting called out
> of sequence.
> >
> > But, now that we are calling the de-constructor on
> close, we need to mode the save geometry code back to it and
> not over ride the closeEvent stuff. I did that for
> notation view, but I will need to apply this to MatrixView,
> and ListEditView if this method was used to save the
> geometry. I'll take that on as well.
> >
> > I did not commit things yet, since I still have a
> glitch where BaseTool and NotationTool are recursively
> destroying each other it appears...hmmm.
> >
> > still sorting that out.
> >
> > But, I'm making good progress on this.
> >
> > Keep you updated.
> >
> > Sincerely,
> > Julie S.
> >
> > PS -- Please don't take this as finger pointing. It
> is not.
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free
> Crystal Reports 2008 30-Day
> > trial. Simplify your report design, integration and
> deployment - and focus on
> > what you do best, core application coding. Discover
> what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Rosegarden-devel mailing list
> > [email protected]
> - use the link below to unsubscribe
> > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
> >
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
