Re: [Flashcoders] more _lockroot woes
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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] more _lockroot woes
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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] more _lockroot woes
Hi, no I was having _lockroot problems. greetz JC On 3/4/07, Ron Wheeler [EMAIL PROTECTED] wrote: 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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 ___
Re: [Flashcoders] more _lockroot woes
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 ___ Flashcoders@chattyfig.figleaf.com 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
[Flashcoders] more _lockroot woes
Hi, I asked a question a few weeks ago about a strange phenoma with _lockroot, losing the reference to the _root I really needed. I seemed to have narrowed it down a little further. Flash seems to lose the way when you reference _root from an instance of a class that is not a movieclip. Especially when that class was already loaded into the parent swf and then used from the sub.swf. Can anyone confirm this behavior? greetz JC ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] more _lockroot woes
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 On 3/2/07, Hans Wichman [EMAIL PROTECTED] wrote: Hi, I asked a question a few weeks ago about a strange phenoma with _lockroot, losing the reference to the _root I really needed. I seemed to have narrowed it down a little further. Flash seems to lose the way when you reference _root from an instance of a class that is not a movieclip. Especially when that class was already loaded into the parent swf and then used from the sub.swf. Can anyone confirm this behavior? greetz JC ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
