[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: ACCENTS.PM clarification?



** Reply to note from Robert Hemenway  Sun, O6 Sep 1998 18:51:14

> I've at last got to your programs on XYWWW, for which I'm extremely
> grateful. Downloaded ACCENTS.PM and incorporated it in SMARTSET.
> Works like a charm, but I had a little trouble figuring out the
> right keystrokes.

> I was getting the wrong scancodes for the three shifted keys,
> Alt + ", etc. So searched "scancode" in my
> \tech\xywrite files and found an exchange between
> you and the Billerica sysop back in Feb 93, with Carl entering in,
> that cleared things up. The three shifted codes in ACCENTS.PM
> are the scancodes for the *final shift state in the KBD
> listing*, whatever it is. In your KBD file it's apparently ALT,
> in the default KBD it's CAPS, in mine it happens to be REDDOT.
> (That's the gray Insert key; I put a little red nail polish on it )

> There's a one-line explanation of this in VA.DOC but nothing in
> the printed manuals that I could find. Wanna add a little Help to
> ACCENTS.PM, with a note on this?

> Regards, Robert Hemenway


Thanks for your remarks, Robert. Glad you're liking the XyWWWeb utilities.
The scancodes are a real bear, and worth going into in some detail, I think.
Your analysis of ACCENTS.PM doesn't go far enough. You need to start with
the realization that XyWrite user-programming has no way, to my knowledge,
of determining which multiple of 256 to assign to shifted keys (short of
opening up your KBD file and examining the ;DEFINITIONS stanza, as my
IDKEY.PM has always done). The formula for Scancode is:
 scancode=(256*2 to the power of b)+a
where
 a=unshifted scancode
 b=position of Shift key in ;DEFINITIONS stanza (counting from the bottom to
the top, and beginning with zero; remember that 2^0 equals 1)

Take for example the letter "V". The raw unshifted keycode (scancode)=47.
If the last DEFINITION is REDDOT, then Reddot_V=(256*2^0)+47=303
If the second-to-last DEFINITION is CAPS, then Caps_V=(256*2^1)+47=559
If the third-to-last is CTRL, then Ctrl_V=(256*2^2)+47=1071
And so on up to the top definition in the stanza. If you had six Shifting
keys defined, and the topmost one was RightCTRL, then
RCtrl_V=(256*2^5)+47=8239.

This rather clever system is additive. If multiple shifting keys
are depressed -- say, Reddot_Ctrl_V -- then the resulting scancode is 1327,
or (256*2^0)+(256*2^2)+47. All of this makes a lot more sense, both
visually and digitally, when rendered in binary (base2), a.k.a. the
language of the machine:
 00000101111 = 47 = unshifted V
 00100101111 = 303 = Reddot_V
 01000101111 = 559 = Caps_V
 10000101111 = 1071 = Ctrl_V
 10100101111 = 1327 = Reddot_Ctrl_V
Here, ones and zeroes function literally as ON/OFF switches for the various
Shifting keys. Just glance at the columns!

Now, how do I deal with this in ACCENTS.PM? I can't determine on the fly
which precise shifting key is depressed; but I can tell, if the value
exceeds 255, that _some_ shift key is being used. My specifications "Alt v"
and "Alt ," etc, are a MicroSoft-like gross simplification, intended only
to ensure that user depresses _at least one_ Shifting key. I don't
actually care whether user hits Alt-V or Ctrl-V or PageUp+Ctrl+Reddot+V --
or whether the Alt key has the largest or smallest base value in the
DEFINITIONS stanza -- as long as pressing Alt results in a scancode over
255 and "V" is the underlying keycode. The logic of the program takes
care of the rest, as follows:

Look at LaBel D ≪LBD≫. Just before LaBel D we put the scancode into
Save/Get 01. Then, if the value of S/G 01 exceeds 511, we repeatedly loop
≪GLD≫, subtracting 256 on each pass, until the value drops below 512. We
don't care how high we start, because in the end, we're going
to have a scancode of 256 plus the value of the unshifted key (or 297, in
the case of V). In short, the only distinction that ACCENTS draws is
between a shifted and an unshifted V. I can't reasonably ask users to alter their
KBD files, or the program nuts & bolts, so that scancodes and KBD files coordinate
precisely. Nobody would bother with it.

So that's the theory. If I bungled the practice, I'd like to fix it.
You don't explain what exactly doesn't work for you when you use the Alt
key with ACCENTS... Seems to work here with a variety of KBD files.



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