PF> lock/unlock,since you're not supposed to be doing much in there
 PF> anyway. Just lock,draw, unlock, in quick succession.

 JP> That's what I will probably do ... But still there is
 JP> a problem : how can I make my application run in the
 JP> background ?


You don't!

 JP> A "solution" is not to lock the screen,
 JP> but then there is corruption when switching :-( Do you

If you don't lock the screen, then the physbuf pointer should cause a trap
as soon as you access it.

What you are supposed to do is one of the following:

       1) Call VioScrLock() with the "wait" parameter.  If your program
       is not in the foreground,  it will be suspended there until it is
       switched to the foreground.  For most grpx apps,  this is just
       fine.  If this doesn't appeal to your program,  I'd like to know
       why.

       2) Use VioSavRedrawWait() in a thread to monitor session changes.
       When switched,  your code will skip doing the Lock/Draw/Unlock
       step.  When the VioSavRedrawWait() thread detects being switched
       to the foreground,  you repaint everything.  See also
       VioModeWait(), VioSavRedrawUndo().   This is starting to get
       complicated -- I think option 1 is better,  as it will suspend
       the program when the user is not using it (I'm thinking that you
       are writing a game).

 JP> have an idea ?
 JP> The reason I want to do that is because I am going to
 JP> develop a game with music and I don't want it to stop
 JP> .. Do I have to play the music in a separate thread ?

If I were the user of your program,  I WOULD want the music to stop if I
switched away.  You may want to use VioModeWait() just for that purpose,or
occasionally check to see that you are the foreground session (from the
info blocks).

In any event,  you should be playing the music in a different thread,yes, 
not because it has anything to do with session switching;  it just makes
more sense!.

 JP> Another question : is it possible to use MMPM/2 to
 JP> play the music if the application is not PM (in this
 JP> case, full screen graphic) ?

I don't know.  I yanked out MMPM/2,  when I discovered it was using up gobs
of memory even if you don't run any part of it.


--- Maximus/2 2.01