> > 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.
>
> Or another object that manages swapping of the members.
dunno. starts to make the QTMovieObject a manager object. I would put
this functionality inside the QTMovieObject myself. see my comments on
passing in a list of parameters in the previous posting.
> > Special handler? Aha. Warning bells ring in my head. (See below)
>
> > 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 missed that one. I do agree with Brennan on this.
> Particularly with item
> 3. This looks like one of those instances where you got to
> ask "Why would
> another object need access to the getCurrentPosition method?"
> Would it be
> perhaps better to have any of that functionality pushed into
> the QT object
> or perhaps I need another object to manage this functionality
well, this is of course the real time data that many other objects &
sprites would likely need. thus I would probably make this public
data, put into a global. I don't know what the ramifications are of
many objects & behaviors testint the QT for its location, but it's not
trivial. why not just let a single object be responsible for that
piece.
> With item 2 (the monitorPlaybackStatus method) I
> would more likely
> view that as an internal/private method that is not made
> available to other
> objects... Depends really on it's required functionality.
as you say it depends on what other objects are doing. if there is
something that might need to know on a regular basis if the movie is
running or stopped or loaded & ready, then it should be public data.
if not, then private. I could imagine that other objects could use the
status.
> Or perhaps any widget that communicates with the QT object
> and vice versa
> should be managed as a group. Often times I use widget
> manager object to do
> this and have it communicate with other objects. It has been
> my experience
> though that the overhead in writing that object only pays off
> when you have
> complex interaction between your widgets. In this particular
> case it may be
> overkill.
I kind of like Brennan's callback concept. an object/behavior could
add itself & it's callback method to a list in the QTMovieObject &
that would get called apropriately, passing the desired info. wouldn't
that be like your widget manager?
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!]
