Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvia!scottb
From: scottb@hpcvia.CV.HP.COM (Scott_Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: another INPUT-command (was, re: progr. ALPHA)
Message-ID: <31210049@hpcvia.CV.HP.COM>
Date: 10 Aug 90 18:53:25 GMT
References: <1990Aug9.201843.3144@sun1.ruf.uni-freiburg.de>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 56

Regarding the current thread of an INPUT work-alike:

One alternative to the program just posted is to use PICT and GROBs.
Every time a character is received, convert it to the appropriate
alphanumeric character, convert it to a GROB, and paste it onto the
end of the existing command line.  Backspacing is simple if you use
a monospaced font (i.e., NOT size 1).  If you have access to the HP
Equation Solve Library Application Card, then take a look at the
interactive molecular weight calculator (accessed by pressing alpha
when running the Periodic Table application).  This uses the method
I just described, and is reasonably fast.  It would run faster if
there didn't have to be checks on the subscript widths (they are 
smaller than the normal characters).  (Note:  This discussion about
the molecular weight calculator is all reverse engineering; I have
never seen the actual code.  But I did try to duplicate it.)

The bottleneck when using user code is the conversion from the row-
column.plane description of a keypress (using WAIT) to the correct
alpha-numeric character.  The approach taken in the previous program
is a list look-up table.  This is not the fastest way available.
A speedier way would be to first explode a list of the available 
characters onto the stack:

 { "A" "B" "C" "D" "E" etc. } OBJ->

  6: etc.
  5: "D"
  4: "C"
  3: "B"
  2: "A"
  1: size

Then, when you receive a character code, find its POS in a different
list:

 { 11 12 13 14 15 16 21 22 23 etc. } code POS

Then use that result to do a PICK to get the right character.

The general point is it's MUCH faster to use the stack than to 
search through a list.


Other notes about the code:  It is faster to do IFT and IFTE commands
than to do actual IF-THEN-ELSE-END constructs.  The IN program can
be easily rewritten to make use of this.  It's not a huge difference,
but it can be detected.  There are other simple optimizations that can
be made, such as replacing "DUP s SWAP" with "s OVER", but I won't go
through it all.  Seeing these sorts of 'packs' just comes with lots of
programming.

Overall, IN, with a few modifications, is one of the most useful 
interface tools I've seen posted.  Good job!


scott.