From: John_Miller@mindlink.bc.ca (John Miller)
Subject: Re: quicktime and hypercard
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 6 Nov 1992 22:44:19 GMT

In an article whose number I forgot to save :), Lawrence D'Oliveiro
writes
>In article <16917@mindlink.bc.ca>, John_Miller@mindlink.bc.ca (John Miller)
>writes:
>>
>> [As an aside, when I read the description of EnterMovies and
>> ExitMovies -- particularly the clarification in Apple's
>> DTS Q&A Stack -- I don't see how any XCMD that plays
>> QuickTime movies asynchronously can guarantee compatibility
>> both with the current version of HyperCard (which knows
>> nothing of QuickTime) and a future version of HyperCard
>> (which will presumably know of, support, and initialize
>> QuickTime).
>
>So the XCMD calls EnterMovies before it loads and starts the movie playing,
>and ExitMovies after it's stopped and disposed of the movie. You can have
any
>number of such calls running concurrently, or overlapping, or whatever.
>A future version of HyperCard might call EnterMovies when it starts up,
>and ExitMovies when it quits. In each case, the number of ExitMovies calls
>equals the number of EnterMovies calls, and the lifetime of each currently-
>loaded movie always lies within at least one pair of EnterMovies/ExitMovies
>calls at every point. So what's the problem?

EnterMovies/ExitMovies are documented to setup/dispose private
state information for the Movie Toolbox.  The problem I have
is that the Movie Toolbox Q&A says that multiple calls to
EnterMovies -- rather than incrementing a usage counter
for the QuickTime world associated with that A5 world --
allocates and sets up a new QuickTime world.

Consider a mythical future HyperCard 3.0 which contains
built-in QuickTime support.  Here is a possible sequence.

1) Hyp 3.0 starts up and calls EnterMovies, creating
   QuickTime World A.
2) A script makes use of a NiftyMovie XCMD to start playing
   Movie1 asynchronously.  (It has some nifty feature
   that isn't provided in Hyp 3.0's built-in support).
   As part the XCMD's initialization, EnterMovies is called,
   creating QuickTime World B and making it the current
   QT world.  Movie1 starts to play.
3) A script now is invoked that starts playing Movie2
   using HyperCard's built-in support. Presumably,
   Hyp 3.0 would make no call to EnterMovies at this
   point.  Movie2 is created "into" the current QuickTime world,
   World B.  Movie2 is a nice long movie.
4) Movie1 finishes playing.  NiftyMovie XCMD cleans up
   after itself and calls ExitMovies.  This disposes
   of QuickTime World B and returns QuickTime World A
   to being the "current QuickTime world."

At this point, Movie2 is still playing but the QuickTime
world it "belongs to" no longer exists.  This strikes
me as a rather ill-defined situation.

Actually, the same problem occurs now with overlapping
movies -- where each movie can end up calling ExitMovies
on the QT world set up by the other movie's EnterMovies --
and it doesn't seem to do the current version of QuickTime
any harm.  So, perhaps the only implication is that Apple
-- when creating new versions of QuickTime -- faces greater
restrictions on what data structures can be a part of QuickTime's
private state data.

But in any case, my original aside was wrong because
an XCMD could avoid all gray areas by ensuring a
unique A5 for each asynchronous movie.

I guess this is just an overly long way of saying "nevermind." <grin>
(I still don't understand/like this "allocate new state globals
for every EnterMovies call" -- how does MoviesTask access an
application's movie list if not via the state globals? -- but I
guess arguing the matter in the face of the current no-problem
implementation will just serve to make me look silly.)

John Miller
Symplex Systems

Newsgroups: comp.sys.mac.hypercard