The DeskTop library routines for handling icons switched GrafPorts
in a fragile way, which previous changes had broken. Updates to
the volume icon clipping code left the GrafPort used for icon
drawing clipped, and it was not restored correctly before subsequent
file icons were drawn.
Ensure the correct grafports are used everywhere, and reset them
when necessary. Further simplification is possible.
When dragging a selection over a desktop icon, the clipping rect of
the GrafPort used for drawing the outline would be changed. Broken
at some point, but probably only worked by accident. (Zero page fun?)
Introduce a dedicated grafport for drawing the outline.
Also, add some macros for pushorg/poporg
When updating how Calculator calls ROM routines in 88666311 the FSUB
wrapper was missing a PLA. Convert the wrappers into a macro to avoid
such mistakes (D.R.Y.)
Also, updated refs to CHRGET routine.
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.
