🚀 go-pugleaf

In article <8904120448.AA24499@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET ("JOHN ZAFIRIS ") writes:
|I am familiar with the line-A calls and the VDI ((or is it AES)... the GEM
|type) calls for mouse cursor handling.  None clear up the problem.
|I assumed that calling the hide mouse line-A opcode several zillion times
|and then using either the line-A show mouse code with a cleared "mouse hidden"
|counter or the VDI (?) code to show the mouse cursor no matter how many times
|it was hidden (which works otherwise) would fix the problem but it did not.
[...]
|The desktop does not have the problems my shell has.  What does it do?  I have
|tried all the leagal ways of fixing the problem that I can think of.  Does the
|desktop do something illegal?  But then that would actually be legal
|just undocumented.  (Atari-speak)
 
  The desktop, because it is an integral part of the OS, can get away with
some things that applications just can't do.  In this case, when
launching a program, the desktop terminates, the AES shell runs the
program, and when the program terminates, the AES shell starts up the
desktop again.  One of the first things that the desktop does, in order
to clean up after "unclean" applications, is to re-initialize the AES
window and mouse handlers.  This is something that an application just
can't do (legally...)
 
  Until TOS 1.4.  When TOS 1.4 becomes available, a new AES call will
become available with it.  The wind_new() call effectively does what the
desktop needs done after an application has exited; it cleans up after
the application, resetting the AES window and mouse handlers.
 
  I'm sorry that I can't provide an easy solution to your problem, but
that's why the wind_new() function was put into TOS 1.4!

-- 
 Ken Badertscher                 | #include <disclaimer>
 Atari R&D                       | No pith, just a path:
 Software Engine                 |   {portal,ames,imagen}!atari!kbad