During calls, MGTK uses the top half of the zero page to hold the
active grafport and local variables. It normally saves/restores the ZP
on each call so that the application's ZP state is preserved. Per
docs, the ZP1 call with param $00 can be used to disable this; MGTK
will write its state to the ZP and assume the ZP is not touched until
a subsequent ZP1 call with param $80, allowing higher performance.
DeskTop would normally run in this state ($00), except when DAs were
invoked since they could use ROM routines (etc) and expect the top
half of the ZP to be preserved during MGTK calls. But it did this with
a toggle ($00, $80, run the DA, then $00 again). Confusingly, the Calc
(and Eyes, c/o copy/pasta) DA would also attempt to get to a normal
state when running ($80, run, $00).
In rev 30532c31 I disabled DeskTop's toggling around DAs to fix an
issue in the Sort Directory DA (see #119), which might have changed
the overall behavior. The result is that on the IIc+ (and possibly
other hardware, but not Virtual II or Laser 128EX) the Calc and Eyes
DAs would crash.
This change disables use of the ZP1 by DeskTop and the DAs. This will
likely impair performance somewhat due to the save/restore overhead on
each call, but at least this gets us to a "known good state".
Fixes#157, #158
The logic for computing window bounds started with the cliprect
returned by GetWinPort. But if the window content area is offscreen
that rect is invalid. Instead, use the Winfo's position/size records.
Also, significantly simplify the math used to account for borders,
title bars and scroll bars.
Full-screen DAs/Previews assume they were launched from a menu and need to
restore the menu bar and hilite state. If launched via double-click there
is no hilite state to restore; handle this by setting the "last menu id"
to an unused value so the HiliteMenu call is a no-op.
