Phillip George Apley wrote:
Condensed verions of chat follows:
Phill said:
Max suggested I use a callback called 'onlastframe'. I'm looking at
LzSprite.prototype.play = function(f) for guidance. I was planning on
making a playonce version. I still hadn't determined how to
differentiate between .play and .playonce. It seems that the default
behavior in SWF is that it loops (?) so perhaps loop should be the
default. lzx code could specify an attribute from the set {loop | once |
static} to change the behavior.
This should be done at the LZX level. Since media can be arbitrarily
complex (in the case of swf) we don't have any control over if it loops
or not. That's why we send onstop, onplay, onframe and onlastframe
events for media.
What would the 'static' option do?
Tucker said:
This seems to me to be an essential part of the Sprite API, whether a
multi-frame resource auto-plays and whether it loops. It seems to me
this should be settable and the Sprite API needs to support it. I think
Max needs to be 'in the loop' here. Let's start either an email or skype
conversation with max in the loop. the sprite api is really his baliwick
Naively, I would say there should just be two attributes, autoplay and
loop which get implemented in the sprite
Agreed - this only applies to multiframe resource includes though, e.g.
<resource name="tabrsrc" src="animation/"/>
from test/lfc/legals/animation.lzx. In this case, the compiler is
including a series of frames and could make the determination if the
media should automatically start or not. Perhaps we should add an
attribute to the resource tag that specifies the default playback
behavior? In this case, swf and dhtml behavior can be consistent.
First though, there's a regression - test/lfc/legals/animation.lzx in
dhtml is broken in DHTML. The multiframe resource 'tabrsrc' isn't
included in the resource table. This is a regression - can you look
into it?
Thanks!
--
Regards,
Max Carlson
OpenLaszlo.org
