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