hi Miller, hi all,
is there any way for a constructor ('new' function) of an external to know whether an object is 1. loaded from a file, or 2. created from menu (typed in, pasted/duplicated, etc.)?
Krzysztof
GUI objects can do this: give yourself a "save" method that invokes the object differently. Regular text objects probably can't do it reliably, although if there was a good reason for it I could put in a function for detecting this...
cheers Miller
On Mon, Nov 18, 2002 at 04:11:03PM +0100, Krzysztof Czaja wrote:
hi Miller, hi all,
is there any way for a constructor ('new' function) of an external to know whether an object is 1. loaded from a file, or 2. created from menu (typed in, pasted/duplicated, etc.)?
Krzysztof
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
thanks Miller,
does it mean that my object should not be created with an 'obj' message to a canvas (a "#X obj..." sequence)? If so, then, unfortunately, its class has to be loaded beforehand (using a -lib option), in order to plug a new message into somewhere.
Or is it just to be created with an 'obj' message having such arguments, that are unlikely to be typed into an object box?
Am I right, that one cannot customize the 'save' method in such a way, as to be able to distinguish loading from pasting? (Actually, I do not need to tell them apart. I was wrong in my previous mail -- I need to distinguish loading-and-pasting from typing.)
Another question: are declarations in g_canvas.h part of an API? How about using 'gl_loading' flag of the t_glist structure?
In another thread I will try to explain why all this is so important for me right now...
thanks again, Krzysztof
Miller Puckette wrote:
GUI objects can do this: give yourself a "save" method that invokes the object differently. Regular text objects probably can't do it reliably, although if there was a good reason for it I could put in a function for detecting this...
hi again,
...why all this is so important? I have just introduced an 'embedding' feature to cyclone's coll and funbuff. 'Embedding' here means storing the state of a collection object in a patch file, just like it can be the case with Pd arrays.
Implementing it properly right from the start is important, because otherwise there is a risk of future upheavals -- most importantly of making .pd files incompatible with newer, corrected versions of the library.
Currently I am using the 'save' method stored in a class' 'widgetbehavior'. The sequence stored in a .pd file is:
#X obj... -- the same line as usual #C... -- embedding stuff, possibly multiple #C lines #C restore;
The #C symbol (read: 'contents'), apparently not used elsewhere, is bound to an object being created. The 'restore' line takes care of the unbinding.
Now, since the first line in the sequence is a valid creation message on its own, I have to find other way of distinguishing loading from a .pd file (and pasting) -- when the full sequence is always executed, including the final 'restore' -- from other cases (without 'restore').
Ok, there is a whole bunch of other dilemmas: how to plug the 'save' method into text object's widgetbehaviour? why to plug it at all, and not use the 'saveto' method, instead? -- but I do not want to flood the list with more spam...
help, Krzysztof
Btw, my current code does the job, but it is horrible, and likely to be broken by any new Pd release...
-
Krzysztof Czaja -
Miller Puckette