gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash


From: strk
Subject: Re: [Gnash-dev] Re: gotoAndPlay bug in Gnash
Date: Wed, 9 May 2007 22:26:20 +0200

On Wed, May 09, 2007 at 08:42:49PM +0200, Udo Giacomozzi wrote:

> Consider three instances:
> 
> A lives from frames 3 to 5
> B from 8 to 10
> C from 13 to 15
> 
> when jumping from frame 4 to frame 14 (or the other way round), there
> won't be a instance "B" created at any time.

Please test this by adding load and unload event handler to clip B.
I mean *clip* events (those found in the PlaceObject2 tag).
This was my question a long long time ago in this thread :)

> What we know for sure is:
> 
> - instances *created* dynamically never care about gotoAndXXXX

dynamically-created instances do NOT have a timeline.
Their frame count is always 1. Single-frame. gotoAndXXX makes no sense.
Just to make your statment above stronger and fixed in mind.

> - instances created statically react in different ways to gotoAndXXXX,
>   depending on ActionScript code that may have modified the instance

Instances created statically, which we called "Timeline instances" on
the wiki page, are the ones created by PlaceObject{,2,3} tags.
They are instances of *definitions* created by definition tags
(DefineSprite, DefineTextField, ...).
Definition tags declare dictionary items (templates/classes).
Control tags create instances of those classes/definitions, and control
their aspect and lifetime.

Removal and modification of instances trough control tags always use
the "Timeline instance" *depth* as the identifying key.
For example, a RemoveObject tag will say to remove the instance 
at depth 5 from the stage.

Now... the problems arise from the entropy introduced by ActionScript
code, which can "shuffle" the data in arbitrary ways so that statically
defined control tags won't find what they'd expect on the table ...

--strk;




reply via email to

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