> > IMPORTANT NOTE:
> > We need a test for opcode guarding to check if Unloaded and Removed
> > makes a difference there. If the removed character has an onUnload event
> > handler, is the remaining of actions after it's removal from stage still
> > discarded ?
> >
Found related tests in misc-ming.all/opcode_guard_test.c.
"
// should not be executed.
add_clip_actions(mc1, "_root.xcheck(false);");
"
This testcase defines onClipConstruct, onClipLoad, onClipUnload and
onClipEnterFrame event handlers for a static movieclip mc1. mc1 gets
unloaded in its construct handler(by the effect of gotoFrame).
Tests show that:
(1)frame0 actions of mc1 *shouldn't* be executed.
(2)onClipConstruct, onClipLoad, onClipUnload handlers should be executed.
Gnash fails, but I guess it is related to actions order.
--zou
On 10/4/07, zou lunkai <[EMAIL PROTECTED]> wrote:
> > IMPORTANT NOTE:
> > We need a test for opcode guarding to check if Unloaded and Removed
> > makes a difference there. If the removed character has an onUnload event
> > handler, is the remaining of actions after it's removal from stage still
> > discarded ?
> >
> I think the answer is yes. It was tested in
> "testsuite/misc-swfc.all/movieclip_destruction_test1.sc"
>
> There are related comments and code block(in movieclip_destruction_test1.sc):
>
> // No matter onUnload defined or not, the above actions still got skipped.
> //#define DEFINE_ONUNLOAD
> #ifdef DEFINE_ONUNLOAD
> .action:
> // Define onUnload(for deduction)
> mc1.onUnload = function () {};
> .end
> #endif
>
> It was a quick test but disabled for some reason(maybe for testing
> some other cases). I can add some focused tests when I am back.
>
> --zou
>
>
>
>
>
> On 10/4/07, Sandro Santilli <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 04, 2007 at 06:48:45PM +0800, zou lunkai wrote:
> > > > +sr60.removeMovieClip();
> > >
> > > > +check_equals(sr60.getDepth(), -32829); ---->[1]
> > >
> > > > +sr59.removeMovieClip();
> > >
> > > > +xcheck_equals(sr59.getDepth(), -32828); ---->[2]
> > >
> > > If Gnash passes on [1], why should it fail on [2]?
> >
> > Because for gnash sr60 and sr59 both point to the same instance.
> > They both have the same target, the one at lower depth is found
> > first.
> >
> > > we are still using pointers for soft references, right? what's the
> > > result of sr59.getDepth() with Gnash(just interested, I cann't verify
> > > it myself at the moment)?
> >
> > It's -32829.. same as sr60.
> > Gnash goes looking for a rebind when the sprite isUnloaded().
> > Now changing it to check for isDestroyed() instead, which should
> > fix this.
> >
> > IMPORTANT NOTE:
> > We need a test for opcode guarding to check if Unloaded and Removed
> > makes a difference there. If the removed character has an onUnload event
> > handler, is the remaining of actions after it's removal from stage still
> > discarded ?
> >
> > --strk;
> >
>
_______________________________________________
Gnash-commit mailing list
Gnash-commit@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-commit
