From helens!shelby!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvia!scottb Fri Jun 29 00:49:48 PDT 1990
Status: RO
 
Article 2020 of comp.sys.handhelds:
Path: helens!shelby!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvia!scottb
>From: scottb@hpcvia.CV.HP.COM (Scott_Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: HP-48SX MENUS and WAIT
Message-ID: <31210036@hpcvia.CV.HP.COM>
Date: 28 Jun 90 22:19:55 GMT
References: <2024@uc.msc.umn.edu>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 50
 
Okay, here is a test-menu program that displays what I mentioned in a
previous note.
 
It is a polite program, in that it preserves user flags and the last
menu displayed before it was executed; these are standard techniques
if you don't want to muck up the user's settings every time he/she
uses your code.  You can take it a step further and preserve the stack,
but since this code doesn't really do too much on the stack, I haven't
worried about it.
 
The program displays a message and a menu, and then waits for one key-
press.  It returns which key was pressed, in the form rc.p, where r is
row, c is column, and p is plane (1 - not shifted, 2 - left-shifted, 
etc.)  It traps the ATTN key, and returns 91.1 for that key.
 
The listing is just typed in, and is not downloadable.
 
<<
  RCLF RCLMENU -> lastflags lastmenu	@ save flags and menu
  <<
    -55 SF				@ no LASTARGS; see note 1
    { "A" "B" "C" "D" "E" "F" } TMENU	@ build temp menu list
 
    CLLCD				@ clear screen
    "TEST-MENU PROGRAM" 3 DISP		@ display program msg.
 
    ERR0				@ clear ERRN,ERRM; note 2
    IFERR
      -1 WAIT				@ get keypress, show menu
    THEN
      IF ERRN # 0d ==			@ if it was an ATTN press,
      THEN 91.1				@ return the key location
      ELSE ERRN DOERR			@ else propagate the error
      END
    END
 
    lastmenu MENU lastflags STOF	@ restore flags and menu
  >>
>>
 
note 1:  -1 WAIT leaves -1 on the stack if LASTARGS (flag -55) is clear
         default is clear, because LASTARGS can be useful; however, it
         is a pain in this situation, because you would have to check 
         if ERRN==0 and then DROP the -1.
 
note 2:  ERRN and ERRM contain the last error number and message, but
         if the error/abort signal is an ATTN press, it does NOT change
         ERRN and ERRM, but leaves them set to whatever the last error
         was.  Therefore, if you clear them, you know you got an ATTN
         if ERRN is #0d.