hi all,
i'm writing a minimal forth for pd, and i ran into the following problems. maybe someone knows how to tackle them?
1. creating inlets/outlets on the fly (i.e. after an object is constructed) seems to work perfectly, except for them not being displayed in the gui. what should i do to 'refresh' ?
2. is pd's parser available through some api? i'd like to load a textfile and convert it's content to pd messages / lists inside an object's constructor. (right now i need an external [textfile] object to boot a forth object, by sending it code one line at a time, and obviously this is a problem when the object has inlets/outlets).
groete
tom
hi Tom,
Tom Schouten wrote: ...
- creating inlets/outlets on the fly (i.e. after an object is
constructed) seems to work perfectly, except for them not being displayed in the gui. what should i do to 'refresh' ?
changing object's io after creation time is doing so after the object has been connected already...
The natural way is for a user to change the text in an object box. Making this into an object's method is doable, but tricky and rather ugly. There are some special cases, like widget transforming itself into an object box after Tcl/Tk failure, or comment doing the same on demand.
- is pd's parser available through some api? i'd like to load a textfile
and convert it's content to pd messages / lists inside an object's constructor. (right now i need an external [textfile] object to boot a
calling binbuf_read_via_path(), or plain binbuf_read(), loads a text file into a binbuf (an array of atoms). That binbuf may be then broken into pieces on semicolons and commas -- the simplest example is in textfile_bang() from x_qlist.c.
Krzysztof
hi krzysztof,
- creating inlets/outlets on the fly (i.e. after an object is
constructed) seems to work perfectly, except for them not being displayed in the gui. what should i do to 'refresh' ?
changing object's io after creation time is doing so after the object has been connected already...
indeed. though i was looking into the possibility for debugging purposes, so it's not necessary at all. it seems removing outlets while an object is running isn't a good idea either.
The natural way is for a user to change the text in an object box. Making this into an object's method is doable, but tricky and rather ugly. There are some special cases, like widget transforming itself into an object box after Tcl/Tk failure, or comment doing the same on demand.
ok, i'm convinced :)
- is pd's parser available through some api? i'd like to load a textfile
and convert it's content to pd messages / lists inside an object's constructor. (right now i need an external [textfile] object to boot a
calling binbuf_read_via_path(), or plain binbuf_read(), loads a text file into a binbuf (an array of atoms). That binbuf may be then broken into pieces on semicolons and commas -- the simplest example is in textfile_bang() from x_qlist.c.
thanks. this was what i was looking for indeed.
any reason why canvas_current() only works in a constructor? i suppose this has to do with the canvas stack when loading a patch?
when i want to have access to the canvas at all times, i should save it in the constructor, right?
tom
hi Tom,
Tom Schouten wrote: ...
any reason why canvas_current() only works in a constructor? i suppose this has to do with the canvas stack when loading a patch?
when i want to have access to the canvas at all times, i should save it in the constructor, right?
right, canvas_getcurrent() returns 0, unless there is a glist pushed on the #X-binding stack by someone calling canvas_setcurrent() first. That binding is updated whenever an object is to be created -- from a patch file, as well as interactively.
Btw, what you get from canvas_getcurrent() is the containing glist, which may happen to be displayed on parent. So, if you need the actual canvas, rather than just a glist, store that glist in the constructor first, but then call glist_getcanvas() each time it is used.
Krzysztof
-
Krzysztof Czaja -
Tom Schouten