Skip to main content
© Erik 'ES of TEX' Simon, 1989

 "The difference between man and animals is that we don't use our
tongue to clean our genitals."
                                            Rimmer, "Red Dwarf I"


                YOUR SECOND GFA BASIC 3.XX MANUAL
                             - or -
        HOW I LEARNED TO STOP WORRYING AND LOVE GFA-BASIC
                             PART 24
                  CHAPTER TWENTY-TWO - PULLDOWN MENU
                          by Han Kempen

OPENW 0

 Even if you don't need a window,  you could 'OPENW 0' if you use
a  pulldown menu.  The menu-line (y-coordinates 0 to 18  in  High
resolution,  that's where your menu is) is now protected  against
accidental  drawing.  Also,  CLS now won't clear  the  menu-line.
After 'OPENW 0' 19 is always added to the y-coordinate,  so  with
'PLOT 0,0' the point is actually drawn at (0,19).

Desk-submenu

 The  first  submenu in a pulldown menu always is  the  so-called
Desk-submenu,  preferrably  with  the program-name as  the  title
(often  you'll  see  'Desk' or  the  Atari-symbol  instead).  The
following lay-out is used:

     Info                     (or: 'About [program-name]')
     ------------
     Accessory 1
     Accessory 2
     (...)

 If  the  user  chooses  the  Info-item,  you  should  show  some
information about the program in an Alert-box. The AES takes care
of  the  accessory-items,  you simply use  '1,2,3,4,5,6'  in  the
corresponding DATA-line.  If you decide to use '-,-,-,-,-,-'  the
user won't be able to choose an accessory from your program,  but
all loaded accessories still occupy memory.

File-submenu

 Most  pulldown  menus  contain a File-submenu  ('File')  as  the
second submenu. A typical lay-out is:

     New file       ^N        (start work with New file)
     Open file ...  ^O        (use Fileselector to Open a file)
     -----------------
     Close          ^W        (stop Work and save under current
                                   filename)
     Save           ^S        (Save work under current filename)
     Save as ...    ^M        (Make new file to save current
                                   work)
     -----------------
     Print...       ^P        (send (part of) work to Printer)
     -----------------
     Quit           ^Q        (Quit program now)

 With '...' you announce that further input from the user will be
requested,   usually   by  providing  a  filename   through   the
Fileselector or by making a choice in an Alert-box.

 If  at  all  possible,   you  should  offer  optional  keyboard-
alternatives  for an experienced user.  With '^N' you remind  the
user of the <Control> <N> alternative.  The character with ASCII-
code  7  is used as the symbol for  <Alternate>,  but  should  be
avoided in pulldown menus.

 The Quit-choice always is the last item of the  File-submenu.  I
have mixed feelings about asking the user if he "really" wants to
quit  (in  an Alert-box).  If you really want to  ask,  the  item
should be 'Quit...' and you should make it easy to quit by  using
'Yes' as the default-button:

     ALERT 3,"|Do you really| |want to quit?",1,"Yes|No",k

 If the user did not save his current work,  you could point this
out  and  offer  him the choice of returning to  the  program  or
aborting his work.  But please do not ask this if the user didn't
change anything (e.g. in a text or picture).

 By  the way,  never leave the last (rightmost)  submenu  without
options,  e.g.  during development of a program. There must be at
least one option in the last submenu, or it's reset-time.

Edit-submenu

 If  the  program  allows  the user to manipulate  a  text  or  a
picture, the third submenu ('Edit') could contain:

     Undo    <Undo>,^Z
     -----------------
     Cut            ^X        (move from work to clipboard)
     Copy           ^C        (copy from work to clipboard)
     Paste          ^V        (copy from clipboard to work)
     Delete   <Delete>
     -----------------
     Find...        ^F
     Find next      ^G
     Replace...     ^H

                     Procedures (CHAPTER.22)

Functionkey_menu                                         FUNCMENU
 Show a Function-key menu:
     RESTORE function.menu
     @functionkey_menu(choice,help!,esc!)
     ON choice GOSUB proc1,proc2,proc3,proc4
     IF help!
       ' User pressed <Help>, show help-screen
     ELSE IF esc!
       ' User pressed <Esc>, quit program/menu
     ENDIF
 The actual menu is read from DATA-lines.

Number_menu                                              NUMBMENU
 Old-fashioned number-menu:
     RESTORE number.menu
     @number_menu(choice,help!,esc!)
     ON choice GOSUB proc1,proc2,proc3,proc4
     IF help!
       ' User pressed <Help>, show help-screen
     ELSE IF esc!
       ' User pressed <Esc>, quit program/menu
     ENDIF
 The actual menu is read from DATA-lines.

Pulldown_menu, Pulldown_select, Key_select, Message_select
                                                         PULLMENU
 A standard approach for a pulldown-menu:
     RESTORE pulldown.menu
     @pulldown_menu        ! activate menu (stored in DATA-lines)
     REPEAT
       ON MENU
     UNTIL pulldown.exit!
 Procedure  Pulldown_select is called if the user picked a  menu-
item,  Procedure  Key_select is used to process any keypress  and
Procedure  Message_select  is called if the  user  manipulated  a
window.

Scroll_menu                                              SCRLMENU
 A classic number-menu scrolls on the screen:
     RESTORE scroll.menu
     @scroll_menu(choice,help!,esc!)
     ON choice GOSUB proc1,proc2,proc3,proc4
     IF help!
       ' User pressed <Help>, show help-screen
     ELSE IF esc!
       ' User pressed <Esc>, quit program/menu
     ENDIF
 The actual menu is read from DATA-lines. 

Disclaimer
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.