Re: The True Importance of UnDo

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Patricia M. Godfrey"
 on Thu, 07 Aug 2008 21:24:38 -0500


> Yes, that is mind-boggling, but WHAT keys are 115 and 126?

They don't correspond to any physical keys on your keyboard,
unless you have one of those old compositor keyboards with a
zillion keys (which I haven't seen in the marketplace for at
least 10 years, but I haven't been looking for either). So when
you run SCAN*, it is reporting the keys that you _press_, not
all the potential keys that exist!

115 and 126 do exist in theory AND in practice. Indeed, there
are altogether 256 potential keys. If an external program sends
115 or 126 to XyWrite, XyWrite reacts to them. I chose to use
115 for this exercise, leaving 126 for future development.

When you ask "WHAT keys are 115 and 126", the technical answer
is that they are ScanCodes C1 and C2. Microsoft declares these
two keys to be "Reserved" keys -- reserved to what, I have not
the faintest idea. But clearly, they are never used.

> How did you discover it?

By poking an array of all 256 keys, one by one, into XyWrite,
while running IDKEY on Xy4.

> How come others ignore 115 but Xy doesn't?

XyWrite predates Windows. It never learned (or knew about) "the
rules". Among the many keys that don't appear on most physical
keyboards, it happens to recognize those two keys, and ignores
the others.

>> It's the real purpose of the $M frame in UnDo's program suite.

> Is that the frame SpclLst?

No, it's frame $M! Jeesh.

Look, $M is the program (frame) assigned to key 115:
 115=$M
When XyWrite receives a key 115, it runs $M. What does $M do?
First it reads a file in Editor's directory called XYMENU.
XYMENU contains a single line, e.g.:
 #=3
XYMENU is constructed in that fashion so that XyWrite can read
file XYMENU and grab the value "3" **without actually opening**
file XYMENU in a window. To perform this minor miracle, $M uses
the powerful command:
 VA{separator}d:\path\filename,{control}{separator}
The result of running that command is "3".

Specifically, $M is coded thus:
 >JM 2.GetPathQ2 ;*; Get d:\path of EDITOR.EXE
 +"\XYMENU,#=>">;*;
S/G51=e.g.""
 >;*; This executes the  command, and dumps
the result into the same Save/Get that originally contained the
command (in order to be economical). So now S/G 51 = "3".

What do we do with that value "3"? We consult the Menu that
exists in $M ("$M" signifies "M"enu) and look for menu item 3.

Where did XYMENU and this value "3" come from in the first
place? An external program wrote it -- usually the same
external program that subsequently pokes key 115 into XyWrite.
The external program wants XyWrite to execute menu item 3 in
frame $M. A tiny program called XyMenu.exe, mentioned anon and
downloadable from XyWWWeb, can perform this service for anyone.

So we look at the $M menu, and what do we see?
 ==3>BX run \EXTCODE.PMQ2 ;*;

And what is EXTCODE.PM? It is a throwaway file that was written
by the external program, which gives the external program
control over what XyWrite does. In other words, when XyWrite
gets key 115, it is entirely under the control of an external
program, at least for the duration of EXTCODE.PM.

Now, it doesn't have to be this way. The menu might have asked
XyWrite to simply execute some frame in U2. Menu item 1 does
exactly that -- it runs frame TUD, which makes an UnDo backup
(here, UnDo.exe is responsible: it wrote XYMENU "#=1" and
then poked key 115). Menu item 2 saves the Stack. At present,
there are only three menu items in $M -- although item #3 can do
just about anything.

One key principle is that any action undertaken by $M should not
interfere with your manual keystrokes, or (generally speaking)
do anything in a XyWrite text window. UnDo adheres to those
rules.

Here's a demo of how $M works. Grab these three files from
XyWWWeb:
 http://users.datarealm.com/xywwweb/MyPID.exe
 http://users.datarealm.com/xywwweb/XyMenu.exe
 http://users.datarealm.com/xywwweb/XyMenu.bat
and put them all in Editor's directory. Run the following
command from XyWrite's command line:
 do/nv/x/z C:\XY4\MyPID.exe
replacing "C:\XY4" with whatever Editor's directory is. That
command would normally be run as part of STARTUP.INT, and is
necessary to establish the ProcessID of XyWrite. Leave XyWrite
running.

Now go to a DOS Prompt on your Desktop. Situate in Editor's
directory. Command:
 XyMenu.bat
and watch what happens.

[Later: example usages of this concept.]

R.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------