On 11/19/2011 05:39 PM, Ivica Ico Bukvic wrote: > I guess this is mainly for the Pd devs, > > Jonathan and I have been working on trying to have patch close itself > through the script. However, even in the newest Pd the problem persists > in that if one invokes menuclose via patch it crashes pd. I suspect this > is because the closure happens while Pd is still traversing the tree and > then trips up on newly deallocated memory pool invoked by the pd_free. > > Initially, I designed a workaround where pd_free is enqueued on the > guiqueue and invoked a bit later ensuring that it is called after the > tree navigation has ended. This works in most cases but not all. > Intermittently this will crash Pd when using Jonathan's Nav abstraction > which closes the current patch and also opens a new patch (navigation > abstraction would be used to go between help files always keeping only > one patch open at a time). Attached is Jonathan's abstraction. > > So, now I started investigating further and it seems that > canvas_vis(x,0) closes the patch without any problems and without having > to delay anything but this is not enough in and of itself to actually > deallocate the actual t_canvas x and other instantiated objects > associated with the canvas. So, how could one go about to implement this > feature?
you could just use [canvasdelete] from iemguts. send a "bang" to [canvasdelete] and it will delete itself sand a "bang" to [canvasdelete 1] and it will delete the containing abstraction. that is, it will not close an opened patch (es opposed to an abstraction contained within a patch), but it should be simple to add this functionality to the existing framework. famsdr IOhannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
