Re: HELP, ETC

[JOE SOLLA]

I know, I know, real men don't use "help" systems.

As I recall, it was trying to read the config.int file on the Xy distribution
disk that piqued my interest in the xpl language. Doing the same thing with the
long.hlp file was boring. A bunch of memory & disk hogging frames that really
couldn't substitute for reading the manual. Some new sorts of help frames were
added to the program (but not to long.hlp) as the eons passed, but again,
nothing exciting. Then they put a file called sample.hlp on the disk that came
with the limp xpl manual they put out awhile back. That was interesting in that
the fill-in screen presented to the user could import data back to the screen
that called it. Still didn't seem to me to be anything more than a way to
automate the creation of mail merge lists and the like. Never really got into
it.

Then I looked at an elaborate integrated system of xpl and hlp files put
together by Karl Manheim and read the chapter on help systems in Tyson's book,
and started playing around with the idea of moving all the various xpl tools I
use into a ram-based help file. The first noticeable benefit was a savings in
memory. Xpl programs, when loaded into memory on an &sgt or during execution
from the disk, share a 64k buffer with all sorts of other crap - the printer
file, the kbd file - and other stuff the company only hints at. You know you've
filled the buffer when the program code comes spilling out into the display
during execution. Help on the other hand, gets its own 64k buffer. And, the
design of the help system allows you to put some stuff (like a type 1 frame)
all in memory, but otherwise puts only the label (the {{xxx}} part) in memory
and leaves the rest on the disk. I'm sure you realize that having the whole
help file on the ram disk is near as fast as having all the programs it
contains loaded into memory and ready to go at the press of a button. eh?

The next impetus was something I'm sure all of us consider from time to time.
If I were to visit your house, and wanted to run my version of XyWrite on your
computer, what would I have to bring with me? (answer: my computer!). My
methods had (have) become so scattered that I'd find myself writing xpl
routines I'd already written. The notion of a single file sitting in the ram
disk, not conflicting with other system memory requirements, containing
everything a boy could ever want.....well you get the picture.

Maybe the best way to demonstrate that help files need not be confined to what
you thought a help file was is by attaching a little piece. Here's a section of
a help file that manages deletion of text and files. It uses a few different
types of help frames. Add it, as is, to some help file in your system. Put it
near the top of the help file just to be sure the names I use don't conflict
with some other label in your help file. Then put the whole file on the ram
disk. Load it. Assign $E to a key (or issue the command: func $E) and see what
it does - try it with a directory displayed, then a file, then a blank screen.
It doesn't erase anything from the disk without giving you a chance to change
your mind.

Bear in mind that my aim is **not** to write routines for the masses - just
demonstrate the interrelationships between the "help" system and the xpl
language. Cheers.

Last: the Northgate / Ultra........... mine is stamped rev no.: 6.04. The OMNI
key does not respond when tst.kbd has a ctl state defined as key "0". Still
getting no use out of this particular key (and no response from XyQuest to my
#4128). When the function assigned to key 76 is preceded by the NI function -
the un-numpad 5 works ok, but the OMNI key performs a destructive backspace.
Weird.

*Enclosed File: e.hlp