--- Dan Willemsen <[EMAIL PROTECTED]> wrote:
> The problem that i see with that is bloat.  What if
> eventually we have
> 20-30 different animations, that would be too many
> events for everyone
> to remember, and for us to implement.

You are correct. Things can get complex with many
animations. In that case we can just standardize on
thread events and then use a type argument to identify
the animation. For exampe:

e={
   onthreadfinish:function(e,type){
      if(type=='slideanimation'){
         // some code here
      else if(type=='glideanimation'){
         // some code here
      }else{
         // some code here
      }
   }
};

The above will work for any animation that uses the
Thread object. But what about those (e.g. Fader,etc)
that does not use the Thread object?

Wouldn't it be better to use the following with the
above type argument?

onfxstart
onfxstop
onfxfinish

example:

e={
   onfxfinish:function(e,type){
      if(type=='slideanimation'){
         // some code here
      else if(type=='fader'){
         // some code here
      }else{
         // some code here
      }
   }
};


--
Raymond Irving

> Dan Willemsen
> 
> On Wed, 2003-03-12 at 08:37, Raymond Irving wrote:
> > Hello Everyone,
> > 
> > I've been doing some thinking about the events
> used by
> > the various animation classes.
> > 
> > What if I want to slide a layer to x,y then when
> the
> > slide is completed I would then glide that layer
> to
> > x1,y1. When the glide is completed I want to then
> run
> > the said layer along a path using PathAnimation
> class.
> > After that I would then like to etc, etc.
> > 
> > How could I then listen for the events?
> > 
> > If we used threadstart, threadstop,etc for the
> events
> > then I would have to add code inside the thread
> events
> > to identify with animation has just been
> completed.
> > But if there was a way to identify the animation's
> > event?
> > 
> > For example:
> > 
> > onsliderun, onslidestart, onslidefinished, etc
> > ongliderun, onglidestart, onglidefinished, etc
> > onpathrun, onpathstart, onpathfinished, etc
> > 
> > for native thread events the Thread class would
> invoke
> > the threadstart threadstop, etc events.
> > 
> > This in my option would allow a user greater
> > flexibility to create complex animations.
> > 
> > Are you in agreement with these event ideas?
> Should I
> > go ahead and implement them?
> > 
> > --
> > Raymond Irving
> > 
> > 
> > 
> > 
> > --- Raymond Irving <[EMAIL PROTECTED]> wrote:
> > > 
> > > --- Dan Willemsen <[EMAIL PROTECTED]> wrote:
> > > > I vote for thread's events.  The only question
> i
> > > > have is if
> > > > PathAnimation's cancel is represented by an
> event
> > > in
> > > > Thread, i cannot
> > > > remember currently.
> > > 
> > > Well PathAnimation uses pathcancel while Thread
> uses
> > > threadstop.
> > > 
> > > Any one else for thread's events? going one...
> going
> > > twice :)
> > >   
> > > --
> > > Raymond Irving
> > > 
> > > 
> > > > Dan Willemsen
> > > > 
> > > > On Mon, 2003-03-10 at 21:45, Raymond Irving
> wrote:
> > > > > Hello,
> > > > > 
> > > > > I think we need to select on event for
> Thread
> > > and
> > > > > PathAnimation objects. Inside Thread these
> > > events
> > > > are
> > > > > used:
> > > > > 
> > > > > threadstart
> > > > > threadrun
> > > > > threadfinish
> > > > > threadstop
> > > > > 
> > > > > While PathAnimation uses:
> > > > > 
> > > > > pathcancel
> > > > > pathfinish
> > > > > pathrun
> > > > > 
> > > > > DynLayer's built-in slideTo() also supports
> > > > > 
> > > > > pathrun
> > > > > pathfinish
> > > > > 
> > > > > While SlideAnimation's slideTo methods uses
> > > > > 
> > > > > threadrun
> > > > > threadfinish
> > > > > threadstart
> > > > > threadstop
> > > > > 
> > > > > 
> > > > > Which of the two should be standardize on,
> path
> > > or
> > > > > thread?
> > > > > 
> > > > > 
> > > > > --
> > > > > Raymond Irving
> > > > >
> _______________________________________________
> > > > > Dynapi-Dev mailing list
> > > > > [EMAIL PROTECTED]
> > > > >
> > > >
> > >
> >
>
http://www.mail-archive.com/[EMAIL PROTECTED]/
> > > > -- 
> > > > Dan Willemsen <[EMAIL PROTECTED]>
> > > > 
> > > 
> > > 
> > >
> __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Web Hosting - establish your business
> online
> > > http://webhosting.yahoo.com
> > > 
> > > 
> > >
> >
>
-------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > [EMAIL PROTECTED]
> > >
> >
>
http://www.mail-archive.com/[EMAIL PROTECTED]/
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - establish your business
> online
> > http://webhosting.yahoo.com
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by:Crypto Challenge
> is now open! 
> > Get cracking and register here for some mind
> boggling fun and 
> > the chance of winning an Apple iPod:
> >
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> >
>
http://www.mail-archive.com/[EMAIL PROTECTED]/
> -- 
> Dan Willemsen <[EMAIL PROTECTED]>
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/

Reply via email to