Re: XPL early programming decision - whether to RC loop or custom .kbd

["Timothy Olson" TLO@xxxxxxxx]

My vote is for RC as well. That way the user has full access to normal functions during the time when the program is capturing and evaluating the user's keystrokes. You could also set up the RC routine to disregard user input unless it's certain characters (such as y/n or others). A program I wrote years ago (in Xy3) had a fairly complex combination of all of these. The program would search a file for a number of "possible" errors (stranded puncutation, improperly spaced ellipses, unbalanced parentheses, smart quotes facing the wrong way, and on and on). Upon finding one of these possible errors, the program would prompt the user about correcting it. In each case, the program asked the user if it was OK to correct the error in a specific way. For example, "Delete space?" [before the stranded punctuation]. If the user pressed y or Enter it would delete the space; if the user pressed n it would search for the item again; if the user pressed Esc the program would terminate; if !
the user pressed any other key it would just beep. There was also one additional option--at any
point the user could press @ and the automated correction would "suspend" so the user
could correct the error a different way (For example, deleting the actual punctuation character, or
deal with whatever else the user happened to notice in the vicinity). When the user pressed @ again
the program would resume where it left off. Haven't used the program in years, but it was great
homemade "proofreading software."


>>> "Young For Life Products, Ltd"  11/07/01 03:41PM >>>
I am starting to write this XPL overview program, for organizing ideas and
pieces in a writing project, and I have a key decision to make:

for a screen which the user will use frequently, entering and exiting it
automatically as they dip in and out of various parts of the whole project,
I need to control the keyboard. Probably about twenty different actions,
including cursor control to specific places on the screen, and menu actions.
In addition there will be allowed input of alphanumeric characters for
placing names in various parts of the screen.

I can either write a series of RC loops that leaves the default keyboard
alone, just temporarily captures input while the user is at that screen, or
I can temporarily load a special keyboard for during the time the user is at
that screen, and when that screen is exited, the user's default keyboard is
reloaded.

When the user is actually writing in a part of the project, not overviewing
the whole project, they are in a file and are not actually in the overview
program any more. All xywrite functions are available. When they go to save
the file, they invoke the program again through a hotkey or command line
command, and the program stores the file properly within the framework of
the overview program.

I incline toward the RC loop while at the overview screen, but am curious
how expert programmers would handle this. If I went with the .kbd idea, I
have to figure out how to capture the info of what .kbd file is presently in
use (I assume there's a function call for that) before invoking the overview
screen and temporary overview keyboard. I guess I could just assume it would
be called xy4.kbd, write it just for xy4 and let xy3'ers rewrite that part
of the program, but that still seems risky, considering the sophistication
of many of the people likely to use this program.

Charles