[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Archive questions (OS X crash)
On 12/30/05, kernel <le_kernel@xxxxxxxxxx> wrote:
> w = SCWindow.new.front;
> 8.do{|i| SCSlider(w,Rect(100.rand,100.rand,20,20))};
> w.writeArchive("/aSCWindow");
> x = Object.readArchive("/aSCWindow");
> x.view.children;
>
> x.front;
> x.alpha_(0.5);
>
> either of the last two lines will crash SC. Cocoa objects can't be
> archived? I'm curious as to why.
> what else can't be archived?
Hmm... archiving an array is one thing because it's just data. The SC
GUI objects are (if I'm not mistaken) just hooks into the cocoa
objects that do the actual work. So if the archive doesn't contain the
code to re-instantiate those objects, then you could wind up with SC
objects that look like GUI objects but that aren't pointing to
anything valid.
This question has come up before of using GUI objects as a storage
mechanism for a performance configuration. That strikes me as an
incredibly bad idea. Felix, in fact, said so in that discussion, but
his post was basically ignored.
"the gui objects should set the state of some model where the values
are actually kept.
it is the model that you should save.
when you reload or switch models, then they should tell the gui to go
set themselves.
its a mistake to think about the gui objects as being your art /
music and that you wish to save them.
they are just views."
So in terms of archiving, you should be saving the models, and the
models know how to reconstruct the views.
I actually use a slightly different approach, where I set up a fixed
number of views at the beginning, then swap objects in and out of them
as needed. It saves a lot of overhead in terms of removing views and
creating new ones.
hjh
--
James Harkins /// dewdrop world
jamshark70@xxxxxxxxxxxxxxxxx
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman