CFOG's PIP, April 1986, Volume 4 No. 6, Whole No. 42, page 4

Function Keys, Submit Files, and Smartkey

by Fred A. Metz

I'm a free lance translator, and I use my Televideo 802 all day, almost every day, much of the time as a word processor. However, as anyone else who does routine work on a computer, I have lots of routine input just to start up each session, to convert the WordStar codes in my completed jobs to codes which are intelligible to my agent's word processor before transmission to him, to back up files, to squeeze files for "archives", to catalog, and more. Lots of "housekeeping".

It took me about six months of learning my way around CP/M before it dawned on me that those mysterious Submit files were simply queues of the same kinds of commands that I was laboriously entering manually, day after day, and that I could use them. I promptly did so.

Then, after a short, unexpected course in assembly language (administered by Messrs. Waite and Lafore in their excellent beginner's book, The Soul of CP/M), I programmed the function keys on my own machine, and found that by making a key's "message" an instruction to execute a given Submit file, I could do all that work I used to manually enter by hitting just one (well, maybe a couple, if the Submit has parameters) key.

Now, that's really livin'!

But life isn't all a bowl of cherries, even when you got your function keys working Submit files. I found that I had to pay 2K of disk space for every one of those little Submit files on my double density drives. I didn't like it, but didn't know what to do about it.

After buying a copy of SmartKey, I became intrigued with its potential. I found that I could put a "submit string" on a "smart" key using Ward Christiansen's /.COM, and save Submit files. However, this program was written for a one-shot entry of a string of commands, so that you don't have to wait at the terminal for operation "A" to end before entering the command for operation "B", and so on, so that no provision was made to enter any variables for Submit parameters.

[/.COM takes a series of commands entered as parameters on the command line and executes them in the order entered. While it creates a $$$.SUB file to do this, so you do need 2k of disk space for it, this is a temporary file that disappears when the operation is over, so you only need 2k, not 2k for each tile used. -bhc]

Of course, I don't need SmartKey for a /.COM "submit string" - I could just enter the command string as a function key "message" and get the same effect - except that my Televideo has only 256 bytes in total reserved for my 22 function keys, each of which is limited to 64 bytes, minus one control byte for each key. Not much room for many long strings.

It doesn't make much sense to use your function keys in conjunction with SmartKey, if you have any alternate means of programming them, at least for SmartKey II. (I don't know about the original SmartKey.)

SmartKey II translates function keys and its "supershifted" keys identically, so that by defining a function key with SmartKey, you "use up" a potential "supershifted key". If you program your function keys with an alternate means, there's no such overlap, giving you that many more programmable keys

To solve the variable problem - somewhat - I made a "pseudo-submit string" by defining a "smart" key with a multipart definition, so that I could enter the variables as they were needed during execution of the string.

This solution gave rise to several new problems.

SmartKey can't define a variable occurring several times within the string as $n", and then enter the term to be filled in only once when executing the "pseudo-submit", as you can with a Submit file, because there's no Submit program to operating to plug the terms in at the right places. This means that the definition must provide for a break to enter each variable as it is used, and you must be present at the terminal while a "pseudo-submit" is executing and still needs to be provided with terms.

Moreover, if you use the "pseudo-submit" to call up your editor, you can't use SmartKey to make any definitions while using the editor, since SmartKey's "setup" key is dead while a definition is being executed (or if you enter the editor at a point in the multi-part definition where a variable is to be entered, tapping the "setup" key will cause the definition to continue its operation -- sometimes with quite undesirable results -- before you're ready).

Another problem with SmartKey is that some programs won't work with SmartKey present in memory, or won't work fully, or will only work under certain conditions.

SmartKey's publisher (Software Research Technology) says that SmartKey is not compatible with XSUB and DESPOOL, and furnish a replacement program for XSUB for use with SmartKey.

In my own experience, U.S. Robotic's Telpac communications program hangs when SmartKey is in memory, so that I need to turn SmartKey off before using my modem, and then turn it back on afterwards (this can be done with a "submit string" on a "smart" key, if you have no parameters or variables in the submit string).

Also, SmartKey doesn't like to have Write-Hand-Man (Poor Person Software) around. As long as it doesn't know WHM is there, there's no problem, but if SmartKey finds it out, it hangs up. If you want to use the two together, what you have to do is activate WHM after SmartKey is in memory, then turn WHM off before SmartKey is turned off (unless, of course, you just turn off your machine, or do a cold boot).

In spite of all of the problems raised above, there are times that it makes sense to use a "submit string" (a "smart" key invoking /.COM at the beginning of the definition) or a "pseudo-submit" (just a series of commands separated by carriage returns in a SmartKey definition) to save disk space.

1. Use a "pseudo-submit" when you have no arguments (or not very many, or don't mind sitting around to enter them), are not using Christiansen's IF.COM and aren't going to use SmartKey to define keys in an interactive program called by the "pseudo-submit" (ED, WordStar, dBaseII, a spreadsheet, etc.). (It can't, of course, be used if SmartKey is to be turned off in mid-execution so that some incompatible program can be run.) This will save the space occupied by the Submit file on disk, and won't even create a $$$.SUB file during execution.
   
   
2. Use a "submit string" when you are going to use IF.COM, and/or need a submit file without any arguments, especially if you're going to enter an interactive program in which you might want to use SmartKey's "setup" key to create definitions during interactive operations. It can be used if SmartKey is to be turned off in mid-execution, because /.COM creates a $$$.SUB file as soon as the string is read in. The space occupied by the Submit file on disk will be saved.
   
   
3. Use a regular submit file when you have parameters to enter during execution. The Submit file does occupy space on your disk, but you have the freedom to walk away from the terminal while the job grinds on.

COM files in a library can be called from both the "submit string" and the "pseudo-submit" using LRUN, just as you would in a Submit file.

There's another potential way to save considerable disk space with SmartKey if you do a lot of word processing. I used to use a bunch of little "format" files in my WordStar applications, because different of my jobs use different formats. At various times, I was using 10-20K of disk space, and after I'd read the format file into my newly opened work file, I'd frequently have to go back and fill in some information.

Since working with SmartKey, I've found its multi-part definitions ideal for this application. I find that I can enter my heading and margin "dot" commands and the "ruler" line applying to the format, and set tabs, margins, line spacing, justification and other WordStar specifications all with just one key.

SmartKey is a little slow sometimes in entering the "dot" commands, but not much slower than reading in a format file, and then moving about to fill in the variable information.

Following are some examples of the files and strings discussed earlier, in order to give a clearer picture of each of them.

1) SQ.SUB is an excellent candidate for a regular Submit file, because of the number of parameters it uses, and the length of time it takes to run. It saves files which will probably never be referred to again in squeezed format on an "archive" file.

SQ B:$1 B:$2 B:$3 B:$4 B:$5 B:$6
    B:$7 B:$8 B:$9
ERA B:$1
ERA B:$2
ERA B:$3
ERA B:$4
ERA B:$5
ERA B:$6
ERA B:$7
ERA B:$8
ERA B:$9
PIPV B:=A:*.?Q?
ERA A:*.?Q?

As you can see, SQ.COM is on drive A, and the files to be squeezed on drive B. The squeezed version of each file is written to A as it is completed. After all of the files have been squeezed, their unsqueezed versions on B are erased. The squeezed versions are then copied back to drive B, and erased from A.

2) GO.SUB is a Submit file I use to start a word processing session.

l keys
l sk ws
b:
a:ws $1
a:
l if b:errwords.txt continue
era b:errwords.txt
l pip updict2.cmp=updict.cmp

[L - or l - is apparently a version of Lrun.com. -bhc]

GO.SUB loads my function key definitions (KEYS) and SmartKey (SK) from Command.lbr, along with an extensive definition file I use for WordStar and formatting, then switches to drive B (where all of my work files are), and loads WordStar. If I've entered a filename following WS (the 4th line of the Submit file), a work file is opened.

During the WordStar session, SmartKey is in memory and useable.

After the WordStar session, the Submit file returns to drive A. Using If.com [again, from Command.lbr], I look to see if my spelling checker found any errors; if so, I erase the error file Errwords.txt (which has already served its purpose) and back up my supplementary spelling check dictionary file Updict.cmp, in the event that I've added new words to it (if I haven't, I abort the Submit at this point with a ^C.

Here's how this same string of instructions would look (a) as a "string submit" and (b) as a "pseudo-submit". For this example, I've defined both of them on the "[" key.

Of course, the parameter which allow me to open a file in the Submit must be sacrificed, and in the "pseudo-submit", I've had to forego the IF test, too.

Both of these command strings may be keyed in as a single line, by extending the right margin out enough (240 maximum in WS 3.0), or may be on more than one line, as shown here.

a) <[> </ l keys;l sk ws;b:;a:ws;a:;l if b:errwords.txt continue;era b:errwords.txt;l pip updict2.cmp=updict.cmp[v]>

[To accurately enter these commands note that there's a space at the end of each line and the next line's text follows immediately. -bhc]

b) <[> <l keys^ml sk ws^mb:^ma:ws^ma:^mera b:errwords.txt^ml pip updict2.cmp=updict.cmp[v]^m>

The ^M in the SmartKey "pseudo-submit" is a carriage return.

3) Lastly, here are examples of WordStar "dot" commands (a) as they appear in a format file or in a document (I've shortened the "ruler line" so it will fit into PIP's column), and (b) the way it would appear defined on a "smart" key. (As the codes are all standard WordStar codes, I won't bother to explain them.)

(a)

.MT 8
.MB 5
.HM 1
.PO 10
.CW 10
.OP
.. p 2 PO =10; # = 76
..   -----!----------!------!-----------!----R
.HE        Translation from

(b)

<[><^os1^m^ol1^m^or80^m
.mt 8^m.mb 5^m.hm1^m.po 10^m
.cw 10^m.op^m.. p 2 po =10; # = 76^m
^ona^m..^m---!--------!-----R
^qs^v..^p^m^v^of^os2^m^e
.he^I^I^ITranslation from>
<^m^m^m^qr^y^qc>

There are several guidelines to remember in building such a string:

1. Reset margins, line spacing to 1, and clear tabs (the string "^os1^m^ol1^m^or 80^m" at the beginning and "^ona^m" just before the ruler line) before creating the "dot" commands, otherwise the previous settings could affect this format.
   
   
2. SmartKey produces an unwanted <cr> at the top of the file; don't forget to delete it (using the string "^QR^Y^QC" at the end of the file.
   
   
3. Don't let a definition go to a new line when you have ">" as the last character on the line; SmartKey will interpret that as the end of the definition.