So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
The big question for me is what to do is how to handle loadbanged messages which change that state (the Tk widgets aren't instantiated yet) and what to do with messages received when the object instantiated without a GUI representation.
So... I guess I am looking for the über-clever hack that means I don't have to keep a parallel data structure in C space...
.hc
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner a écrit :
So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
The big question for me is what to do is how to handle loadbanged messages which change that state (the Tk widgets aren't instantiated yet) and what to do with messages received when the object instantiated without a GUI representation.
So... I guess I am looking for the über-clever hack that means I don't have to keep a parallel data structure in C space...
.hc
Hello, It seems you need to serialize your widgets, this exemple might be in help:
Patrice Colet a écrit :
Hans-Christoph Steiner a écrit :
So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
The big question for me is what to do is how to handle loadbanged messages which change that state (the Tk widgets aren't instantiated yet) and what to do with messages received when the object instantiated without a GUI representation.
So... I guess I am looking for the über-clever hack that means I don't have to keep a parallel data structure in C space...
.hc
Hello, It seems you need to serialize your widgets, this exemple might be in help:
one more time, I didn't understood the question, forget this...
On Nov 13, 2007, at 5:50 PM, Patrice Colet wrote:
Patrice Colet a écrit :
Hans-Christoph Steiner a écrit :
So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
The big question for me is what to do is how to handle loadbanged messages which change that state (the Tk widgets aren't instantiated yet) and what to do with messages received when the object instantiated without a GUI representation.
So... I guess I am looking for the über-clever hack that means I don't have to keep a parallel data structure in C space...
.hc
Hello, It seems you need to serialize your widgets, this exemple might be in help: http://wiki.tcl.tk/9168
one more time, I didn't understood the question, forget this...
Well, this was useful nonetheless. I was thinking of writing this in C, but perhaps I should use this Tcl function you sent.
.hc
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Hans-Christoph Steiner wrote:
So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
how are you going to do that? when the savefn is called, will you send a request to the pd-gui, stall the pd-engine while waiting for the result (tricky, as the talkback channel will also be stalled) and only then return from savefn?
do you bear in mind that the savefn is called everytime you copy the object or even edit an existing object?
that'll make the widget library pretty much unusable for live patching.
i think a better way would be to dump the "content" of the widget to the pd-engine everytime it is (actively?) changed. you don't need any special structure for this, just store the list in a save place and use it whenever the savefn gets called.
fgamdsr IOhannes
On Nov 14, 2007, at 3:25 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So all of the Tk widgets that I am using save their own state while they are running, then I am planning on querying them when the savefn is called to save their state, and of course, do the opposite when opening.
how are you going to do that? when the savefn is called, will you send a request to the pd-gui, stall the pd-engine while waiting for the result (tricky, as the talkback channel will also be stalled) and only then return from savefn?
do you bear in mind that the savefn is called everytime you copy the object or even edit an existing object?
that'll make the widget library pretty much unusable for live patching.
i think a better way would be to dump the "content" of the widget to the pd-engine everytime it is (actively?) changed. you don't need any special structure for this, just store the list in a save place and use it whenever the savefn gets called.
[text] has 35 options, so I imagine that if I save them every time one changes, that would also be quite heavy. Especially if you are moving a slider on one of the options, or something like that.
Hmm... in need of a tricky hack... I can almost taste it, but I just can't grasp it yet.
.hc
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Patrice Colet