Re: Why I DIDN'T enhance the E (help!)

[dalloff@freenet.columbus.oh.us (Dave Althoff)]

:    Mousetext only appears when you have inversed uppercase letters
: written incorrectly to the screen. (Usually associated with 'freetools'
: progs written before they knew that apple would *** up the charmap).
: Does PFS invert the screen and do everything that way.

Define "incorrectly"!  If using the intrinsic display routine as a model,
then sending the resulting codes through the normal COUT gateway is
incorrect, then yes, that is exactly what is happening.  If telling Apple
Pascal to set the text display to INVERSE and performing a writeln is
"incorrect" then I'd say that the application programmer is not at fault
here, but rather the engineer who decided to monkey around with the wrong
half of the character map.  PFS:FILE uses inverse for ALL of the field
labels...which means that with Mousetext, any uppercase field label
(including not only the database records, but also the program's own menu
selection fields!) will turn into useless little mouse turds.  PFS:File
is, in fact, running under a run-time version of Apple Pascal, though the
PFS: series programs use their own disk I/O routines instead of the Pascal
File System.  Which makes getting data into and out of the PFS: series a
little tough.  I guess we bought the package five years too early, instead
of waiting for the ProDOS version...

: P.S. Yes, I do have my own beef with the way apple implemented
: mousetext. When writing raw bytes to the screen, $80-FF is the set of
: normal characters. One would think that by masking that down to 00-7F,
: one would get inversed characters. Heck no. The lowercase letters
: (60-7F) are fine, but the 40-5F range is mousetext.  To do inverse
: properly, one must mask down to 00-7F, _then_ check if it's uppercase
: and mask it down to 00-1F.

:    If they'd made mousetext 00-1F, all this craziness would be
: avoided. (Yes, that's like the control chars used to control the
: screen. But, if you go thru those chars, things don't matter, and if
: you slam to the screen, it doesn't matter either)

Exactly.  And I really don't have any idea why they chose to have
screen-control characters in the 80-column firmware anyway, since those
characters are NOT part of the display control tradition.  The only one I
ever use is CHR$(21), which shuts off the 80-column display on the
unenhanced E...other than that, I find that the normal intrinsic routine
calls work fine (CLEAREOL, CLEAREOP, HOME, etc.) in either 40- or
80-columns.  The only reason I can think of is if some of the ancient
Videx boards used those codes.  They'd have been better off to eliminate
the screen control characters and use those for Mousetext.

--Dave Althoff, Jr.  (frustrated again!)
-- 
    /-\              /\
   /XXX\       X      X\
  /XXXXX\     XXX    XXXX**>   X           (hard hat area...       )
_/XXXXXXX\__/XXXXX  XXXXXXXX  XXx          (.sig under construction)