> Item 1 - instantiation would probably (and most importantly)
> cache values
> such as movie duration, so we might need to have a special
> handler which
> does this more than once for those situations where we swap
> the member.
>
> Special handler? Aha. Warning bells ring in my head. (See below)

well, we could call it setupMovie. it would be the method that would
be called whenever you swapped a member or started up a new member.
you could build the object such that it could take parameters such as
the movie member name. if no valid member name was passed, it would
just return the reference to the object. if it was passed, it would
get all the properties like the duration of the movie & do whatever we
decide is necessary. i.e.:

 gQTPlaybackObject = new(script "QTPlaybackObject", myMemberName,
myMemberFileName)

then in the object:

 on new me, myMemberName

  if NOT voidP(myMemberName) then
   me.setupMovie()
  end if

  RETURN me
 end


> I have problems with items 2 and 3. These should either be
> public (in which
> case, just use the standard quicktime sprite access calls:
> sprite(s).movierate and so on), or private.

I initially thought of these as private methods that would just get
the data & then publish it as a public global.

> An object who wants this data should have a good reason (a
> slider, perhaps).

a slider or any thing that would want to synchronize to the movie.

> Like I said, the QT wrapper might offer a callback option.

good idea. the object could have a list of objects, sprite behavior
references or the like that would be called in certain instances.

> > I'd suggest
> >
> > 13 - switchFile: switch the member.filename with the no-flash
workaround
>
> When we get into member territory, I get a feeling we might
> need another
> object in there, particularly for swapping filenames. It
> depends how central
> that functionality is supposed to be of course.

I think this is a good idea. this would work with the setupMovie()
method.

> If it was supposed to
> include (say) a playlist functionality, I would argue for a
> seperate object,
> dedicated to handling member swapping. This might also inform
> the QT wrapper
> object or slider controller of the new duration (etc).

I would likely put int in the main object, just to make it complete.
wouldn't do it now tho. however, it would make sense then to make the
parameters you pass in when you instantiate the object be a List. then
you could expand the functionality easier.

how, 'bout that?

Al Hospers
CamberSoft, Inc.
al<at>cambersoft<dot>com
http://www.cambersoft.com

Shockwave and Director development, Lingo programming, CGI scripting.

A famous linguist once said:
"There is no language wherein a double
positive can form a negative."

YEAH, RIGHT



[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi  To post messages to the list,
email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo.  Thanks!]

Reply via email to