(Comp.sys.handhelds)
Item: 2964 by rkb at po.CWRU.Edu
Author: [Robert K. Brunner]
  Subj: HP48 phonebook/list program
  Date: Mon Apr 29 1991
 
For some time I have been looking for a little list manager program to let me
store phone numbers or lists on my HP48.  With no memory cards, I was looking
for something small.  I couldn't find any I liked, so I wrote my own.  The
program is based on an index-card metaphor. Cards are indexed by their first
line.  To save memory, I made extensive use of the INPUT command rather than
writing my own editor.  The whole program is only 2300 bytes (without data).
 
Operation:
 
Download the directory to the 48.  Go into the directory and then into the
FILES subdirectory.  Enter a quoted variable name for the database and press
CARDS.
 
If the database does not exist, a null list will be created and stored in the
variable.  Then the card viewer will start.  The following commands work in
the viewer:
 
Up arrow    - Scroll current card up.
Down arrow  - Scroll current card down.
Left arrow  - Move to previous card.
Right arrow - Move to next card.
ADD         - Add a new card.  Initially the database is empty, so this
              will be the only valid option.
EDIT        - Edit the contents of the current card.  The title line cannot
              be changed.  To change the title, delete the card with DEL
              and retype it using ADD.
DEL         - Delete current card.
FIND        - Search cards for a matching (or closest) title.  FIND prompts
              the user for the search text.
SAVE        - Save the database back to the variable name.  The program
              works on a copy of the database, so if you make a mistake,
              you can just QUIT without changing the database
QUIT        - Quit the card viewer.  The current database is not saved,
              so SAVE should be done before QUIT to keep any changes.
 
Let me know if you use this program.  There are lots of ways it can be
extended, but life is short and SRAM expensive.  The error checking is
nonexistent, which is why I make the user execute SAVE explicitly so the
database does not become corrupted if something strange happens.
 
Robert Brunner
brunner@uirvld.csl.uiuc.edu