Back in the late 1940s, the idea of programs using data to modify their
behaviour was invented.
Prior to that, if you wanted to have a program do something different
depending on the situation, you constructed a bunch of programs and
selected the one that you wanted to run.
You seem to have wandered into a pre-1950 programming mode.
The generally accepted way to solve the problem is to write a Class that
reads data from the server and depending on the data, alters its behaviour.
1) This class is only loaded once so you do not have the problem of
trying to delete the Class definition.
2) The data is generally a lot smaller than the Class definition
3) Data is usually faster to parse than a Class definition
4) The general Class is a bit larger than each specific class but
probably a lot smaller than the total of all of the classes - longer
first load but savings later.
You can write helper classes that can be loaded on demand but they can
have unique names.
Ron
Hans Wichman wrote:
Hi,
yep and thanks for the replies. Well its all ofcourse just corporal
punishment for using lockroot:) One more reason to stay away from it, now
only to find a good replacement:). Very strange though, one case where
I ran
into this problem is, using a main.swf and a sub.swf, where the sub would
lose its reference only after it was loaded the second time. Main did not
contains any of subs classes.
Very strange.
Anywayz thanks all!
JC
On 3/4/07, Brian Williams <[EMAIL PROTECTED]> wrote:
That was kind of my point. He thought the issue was with lockroot,
and I
was trying to say that the issue was probably the fact that the first
version of the class is used (which was loaded before the lockroot).
Every case that I've run into where the root wasn't preserved by using
lockroot was when the class that referenced root had already been
loaded.
--Brian
On 3/3/07, Ian Thomas <[EMAIL PROTECTED]> wrote:
>
> Hi Brian,
> I think what you're talking about is a different phenomenon.
>
> The Flash Player always uses the _first version_ of any class that
> it loads. So if your parent movie has a class com.mydomain.SomeClass,
> and your .swf that loads into your parten movie has a different class
> com.mydomain.SomeClass, then the first one will always be the one
> used.
>
> So be very careful with package naming. :-)
>
> There is a way around it, if you really need to get around it:
> before loading your second .swf, call:
>
> delete _global.com.mydomain.SomeClass;
>
> Any instances of SomeClass which already exist in the parent will
> be fine. And the loaded .swf will use the 'right' version of the
> class.
>
> But it's not without dangers - you can never create an instance of
> the original version of the class again. I'd only use that trick if
> you really really need it.
>
> In short - be careful what you're doing with naming. :-) Avoid name
> collisions.
>
> Cheers,
> Ian
>
> On 3/3/07, Brian Williams <[EMAIL PROTECTED]> wrote:
> > Yes, I've noticed that too. Classes are only loaded once, so if
swf A
> uses
> > class Foo, and then loads swf B into a lockroot, if swf B also has a
> class
> > Foo, it's going to be using the class defined in swf A (with the
wrong
> > root). Note: it's not just the interpretation of _root. class Foo
> from
> > swf A might be a totally different (older, for example) version, but
> that's
> > what swf B will see.
> >
> > --Brian
> _______________________________________________
> [email protected]
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
