Personally, I'm hoping to put band-aids on as many manaifestations of the problem as I can track down (so thanks for this one :) and then re-design the whole editor creation and destruction strategy for 0.44 - it looks like it can never be fully debugged the way it's stet up now!
Miller On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote: > On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: > ... > >Wow! You just helped me finally solve this riddle! Could it be really > >this simple? In canvas_free() call inside g_canvas.c simply add the > >following 2 lines: > > > > if (x->gl_editor) > > canvas_destroy_editor(x); > > > >I added them right below > > > > if (x == glist_getcanvas(x)) > > canvas_vis(x, 0); > > > >Now even if the canvas is recreated with the same memory space there is > >no more double-entry bug. Are there any potential regressions with this > >model? The canvas is getting freed so I cannot imagine this posing any > >problems but then again I am sure I may be missing something... > > this only handles the case when the GOP is part of a toplevel window. > > The other case is when the GOP's parent isn't toplevel. When the > window of such a parent is closed, the canvases themselves aren't > destroyed, but the editors should be. > > So I think the best way is to get rid of sub-editors recursively. > I may be mistaken, though, because there are some partial workarounds > already in the code. Apparently, Miller had been aware of the issue > but then things went their own way, somehow. > > Krzysztof > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev