[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash
From: |
Udo Giacomozzi |
Subject: |
Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash |
Date: |
Wed, 9 May 2007 23:13:31 +0200 |
Hello strk,
Wednesday, May 9, 2007, 10:26:20 PM, you wrote:
>> when jumping from frame 4 to frame 14 (or the other way round), there
>> won't be a instance "B" created at any time.
s> Please test this by adding load and unload event handler to clip B.
Confirmed.
s> I mean *clip* events (those found in the PlaceObject2 tag).
Huh? I simply added trace()s to the three different sprite
definitions.
>> What we know for sure is:
>>
>> - instances *created* dynamically never care about gotoAndXXXX
s> dynamically-created instances do NOT have a timeline.
s> Their frame count is always 1. Single-frame. gotoAndXXX makes no sense.
s> Just to make your statment above stronger and fixed in mind.
Hold on, I'm talking about *instances*. When you call attachMovie() in
_root, and do _root.gotoAndPlay() to an earlier frame, then that
instance will be still there.
- unless you give it a depth < 0 (just checked).
And dynamically-created instances *can* have a timeline
(attachMovie() !!). Or is a "dynamically-created" instance only one
created with createEmptyMovieclip() in your understanding?
>> - instances created statically react in different ways to gotoAndXXXX,
>> depending on ActionScript code that may have modified the instance
s> Instances created statically, which we called "Timeline instances" on
s> the wiki page, are the ones created by PlaceObject{,2,3} tags.
Right.
s> They are instances of *definitions* created by definition tags
s> (DefineSprite, DefineTextField, ...).
Right, but dynamic instances can be defined by DefineSprite too (when
exported).
s> Definition tags declare dictionary items (templates/classes).
s> Control tags create instances of those classes/definitions, and control
s> their aspect and lifetime.
I thought you call these "events" ?
s> Removal and modification of instances trough control tags always use
s> the "Timeline instance" *depth* as the identifying key.
In a SWF file, yes, but have a look at the wiki. Even when the depth
is changed by the script, then the control tags still influence the
instance.
s> For example, a RemoveObject tag will say to remove the instance
s> at depth 5 from the stage.
It also removes it when you do swapDepth(9) before!
So: it's *not* simply identified by the depth at *play* time.
s> Now... the problems arise from the entropy introduced by ActionScript
s> code, which can "shuffle" the data in arbitrary ways so that statically
s> defined control tags won't find what they'd expect on the table ...
I get the feeling that swapping depths of instances between the
timeline space and the dynamic space was never intended by the Flash
designers. It's strange that only depths > 0 can be removed with
ActionScript. So what happens when a SWF does it anyway depends on the
internal implementation of the player, with other words: "undefined
results". Nonetheless we need to resemble the exact same behaviour.
Udo
- Re: Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, (continued)
- Message not available
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re[3]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Eric Hughes, 2007/05/09
- Re[4]: [Gnash-dev] Re: gotoAndPlay bug in Gnash, Udo Giacomozzi, 2007/05/09
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash, strk, 2007/05/09
- Re[2]: [Gnash-dev] Re: gotoAndPlay bug in Gnash,
Udo Giacomozzi <=
- Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash, strk, 2007/05/09