On Sat, 2010-04-03 at 19:40 -0400, Mathieu Bouchard wrote: > > By using [canvasdelete] from the iemguts. It allows to delete certain > > objects of a certain canvas by their index number (for instance, 'delete > > 12'). The canvas needs a [canvasdelete] in order to add the 'delete' > > method to the canvas and a [sendcanvas] to which the 'delete <id>' > > message is sent. > > How do you intend to manage those numbers from Pd without ever getting > mixed up ?
It's actually fairly easy. The GOP's top-level canvas contains a fixed number of objects, that are the required minimum for being able to dynamically delete objects: [canvasdelete], [r $0.sendcanvas]-[sendcanvas], [pd guts], [namecanvas $0.myabs]. So the first dynamically created object will have index 5, the next #6 etc. However, what matters is the number of fixed objects. Let's say I create dynamically 7 additional objects, I just need to send seven times 'delete 5' (the number '5' protects the first 5 objects from being deleted) to [sendcanvas] in order to remove them. > > > Then I ran into another problem: I was creating [cnv] objects in a GOP > > and moving them out of the GOP area, which is a way to display something > > in the parent patch outside the GOP area. However, when deleting such > > gui objects, they remain visible in the parent (as if the parent > > wouldn't be refreshed). > > Why do you want to rely on a bug ? I don't care at this point, whether it is considered a bug or not. Personally, I cannot fix it anyway. It may won't be fixed soon anyway. Although you consider it a bug, I find it a feature. By using mostly Pd when programming, I am kind of accustomed to using kludges. Pick one of those reasons. Roman ___________________________________________________________ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list