gnash-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]