Temporary picts

[J. Landman Gay]

Shari wrote:
> 
> >If so, you could try using "send in" commands to trigger the handler
> >repeatedly. The handler could check to see if the sound was "done" and
> >if so, start the next one.
> 
> After an hour of playing with various forms of the "send" command, I
> gave up and went back to the long, klutzy version.

I did some quick tests. Apparently MC won't queue sounds the way HC
does; as soon as you play a second sound, it will cut off the first. So
using "send in" is the only way to queue sounds, unless you use a "wait
until the sound is done" command, which won't work if you want to
simultaneously issue other commands.

The problem with "answer" is that it displays a modal dialog. Modal
dialogs stop all messages until they are dismissed, meaning any "send
in" commands won't execute until the user dismisses the dialog. In my
tests, the first sound did complete while the answer dialog was
displayed, but of course no further sounds were triggered because no
messages were sent until the dialog was closed.

So the solution has to be to avoid modal dialogs. You could do that by
creating your own dialog stack and storing it as a substack in your main
stack. You'd fill the text field with the appropriate response and set
the button labels to whatever you want. Then display it as modeless:

  modeless "myDialog"

The always-available global "dialogdata" can be used to store the user's
button click response, or you can just have the custom dialog set a
property that you can read to get the button they clicked. The drawback
to using a modeless stack is that the user can click outside the stack
and the custom dialog will pop behind other windows. 

So, no easy way to do what you want I guess.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com