From AtariForumWiki

Revision as of 15:35, 12 October 2011 by Wongck (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


[NOTE: Words enclosed in asterisks (i.e. *word*) should be 
read as italicized text. This text file is copyright 1993 by 
Clayton Walnum. All rights reserved.]

Now that we've covered the easiest of GEM's forms, it's time 
to move on to something a little more complicated--
specifically, menu bars. Although menu bars are easy to 
implement, they require a fairly large chunk of code to 
handle. In this chapter, we'll learn just about everything 
there is to know about menu bars.

--The Program--

In the CHAP3 folder of your *ST Assembly Language Workshop* 
disk are the files PROG3.S, PROG3.PRG, MENU.RSC, MENU.H and 
MENU.DEF. The first two are the source code and the 
executable file for this chapter's sample program. The 
PROG3.PRG file is ready to run, but if you'd like to 
assemble the program yourself, follow the instructions that 
came with your assembler or see this book's Appendix A. The 
file MENU.RSC is the resource file for this chapter's 
program. It must be in the same directory as PROG3.PRG when 
you run the program. Finally, MENU.H and MENU.DEF are the 
header file and definition file for the menu.
	When you run the program, a menu bar will appear on the 
screen. It has four menu titles: Desk, File, Options, and 
Selects. Click on the Desk menu, and then click on the ALW 
Info selection. An alert box will appear, giving you a brief 
description of the program. Click the alert box's okay 
button to remove the box from the screen.
	Now, click on the file menu title. The file menu 
appears, which contains the Load, Save, and Quit commands. 
Click on Load or Save, and an alert box appears, telling you 
which you clicked. (In a full program, you'd get a file 
selector when you select these commands.) Clicking on the 
Quit selection will take you back to the desktop. Don't do 
this yet, though.
	Click on the Options menu title. Then click on any of 
the options. By clicking them, you turn the checkmarks on or 
off. Now, click on the Select menu title. Then click on 
Select 1, Select 2, or Select 3. An alert box will appear, 
verifying your selection. Finally, click on the Off 
selection of the Selects menu bar. This turns the select 
entries off, so that they may no longer be selected. Also, 
the word "Off" changes to "on."
	When you're finished experimenting with the menu bar, 
click the Quit command in the file menu to return to the 

--Resource Files--

In previous chapters, we used forms that GEM provides ready-
made for us. Menu bars, however, must be created by the 
programmer. Once we create a menu bar, the information that 
describes it to GEM is placed into a special file called a 
resource. You've seen plenty of resource files. They're the 
ones with the .RSC extension. In each .RSC file is all the 
data needed to create a program's menu bars, dialog boxes, 
and other GEM objects.
	How do we create a resource file, you ask? We use a 
program called a resource construction program. Two popular 
resource construction programs are RCP.PRG, which comes with 
Laser C, and RCS2.PRG, which comes with the Atari Developer 
Kit. It doesn't really matter which resource construction 
program you use. The resulting .RSC file will be the same, 
because all resource files have a standard format.
	In this book, we'll use RCP.PRG to create our 
resources. If you are using a different resource 
construction program, you'll still be able to follow along. 
You'll just need to modify the steps slightly, since each 
resource construction program operates a little differently 
than the others.

--Creating a Menu Resource--

Your *ST Assembly Language Workshop* disk contains all the 
necessary resource files. However, it's important that you 
understand how to use your resource construction program, so 
below are the steps necessary to create this chapter's menu 
resource. Start RCP.PRG and follow the steps below to create 
the resource file.

   Step 1: Click on the "New" selection from the file menu. 
A window titled NONAME will be opened. This window is where 
we'll work on our menu bar.

   Step 2: Drag the menu icon from the left of the screen 
into the newly created window. A dialog box will appear, 
prompting you for the name of the menu tree. Press Return to 
select the default name of TREE00. The menu tree icon will 
appear in the work window.

   Step 3: Double-click the menu tree icon. The beginnings 
of your menu bar will appear in the work window.

   Step 4: Give the Desk menu selection (on your menu bar, 
not the RCP's) a single click, and then press Control-N. The 
dialog box for naming objects will appear. Name this object 

   Step 5: Repeat Step 4 for the File menu selection, naming 
this object "FILE."

   Step 6: Drag the word TITLE from the parts list and place 
it to the right of the File title. Double-click this new 
menu bar title. A dialog box will appear. Change the text to 
two spaces followed by the word "Options," followed by 
another two spaces.

   Step 7: Place the mouse pointer on the lower right-hand 
corner of the title's shaded area and, holding down the left 
button, expand the shading to the right, centering the title 
within it. Click once on the options title to select it. 
Then press Control-N and name the object "OPTIONS."

   Step 8: Set up another menu title in the same way, 
entering the text as two spaces followed by the word 
"Selections," followed by two more spaces. Name the object 

   Step 9: Give the Desk menu selection a single click. Then
double-click the "Your message here" entry. Change the text 
to two spaces followed by "ALW info..." and press Return. 
Press Control-N, and name the entry "INFO."

   Step 10: Give the File menu selection a single click. 
Then place the mouse pointer on the lower-right corner of 
the QUIT object. Holding down the left button, reduce the 
length of the object by dragging the corner to the left. You 
have to do this in order to uncover the menu box beneath.

   Step 11: Place the mouse pointer on the lower-left corner 
of the menu box and, holding down the left mouse button, 
drag the box downward, enlarging it so that it can fit three 
more entries.

   Step 12: Place the mouse pointer on the QUIT object and,
holding the left button down, move the object to the bottom-
most position of the menu box.

   Step 13: Drag the word "ENTRY" from the parts list and 
place it in the top position of the File menu box, making 
sure you place it as far to the left as it'll go. Double-
click it, and change the text to two spaces followed by 
"Load...", followed by two more spaces. Name the object 

   Step 14: Create another menu entry below LOAD. The text 
should be two spaces followed by "Save...", followed by two 
more spaces. Name this object "SAVE."

   Step 15: Drag the ---------- icon from the parts list and 
place it below the SAVE entry, all the way to the left. Then 
move the QUIT object just below it and name it "QUIT."

   Step 16: Reduce the menu box to its smallest size using 
the same method as when you enlarged it (Step 11). Add 
enough dashes to the ---------- object (by double-clicking 
on it and changing the text) to extend it to the right-hand 
margin of the menu box.

   Step 17: Single-click the Options menu title, and enlarge 
the menu box to fit three entries.

   Step 18: Drag an ENTRY icon to the top of the Options 
menu box. Set the text to two spaces followed by "Option 1," 
followed by two more spaces. Before closing the dialog, set 
the CHECKED option in the attributes list. Name the object 

   Step 19: Create two more entries in the options menu box, 
named "OPTION2" and "OPTION3," and place them in order below 
OPTION1. The spacing of the text will be the same as in Step 
18. Do not set the CHECKED attribute for these two objects. 
Reduce the Options menu box to its smallest possible size.

   Step 20: Single-click the Selections title. Then stretch 
the menu box to fit five entries.

   Step 21: Create an entry in the Selections menu named 
"ONOFF," and enter into the text field five spaces followed 
by "On" followed by five more spaces.

   Step 22: Drag the ---------- icon to a position below the
ONOFF entry. Add two dashes to the already existing ten in 
the text field.

   Step 23: Create three entries below the dashed line. The 
entries should be named "SELECT1," "SELECT2," and "SELECT3." 
Their text fields should contain two spaces followed by 
"Selectn" (where n is the entry's number as indicated by the 
names above), followed by two additional spaces.

   Step 24: Reduce the Selections menu box to its smallest
possible size.

--Setting the Mouse Form--

Now that we understand a little about resource files--
specifically what they do for us and how to create them-- 
let's turn our attention to the program listing. The program 
start with the same type of initialization we've been using 
in all the programs: setting up a stack, releasing memory, 
and calling *appl_init*.
	Right after the initialization, you'll see a call to 
the AES function #78, *graf_mouse*. This function allows us 
to manipulate the mouse pointer in several ways. Using this 
function, we can turn the mouse pointer on or off, select a 
mouse form from the system forms, or even set up our own 
custom mouse form. In this chapter's sample program, we're 
using *graf_mouse* to set the mouse form to the arrow. We 
need to do this because when we run the program, GEM 
automatically changes the mouse form into the busy bee, in 
order to inform the user that the program is loading. 
However, once the program is loaded and running, GEM doesn't 
set the pointer back. That's our job.
	The call to *graf_mouse* looks like this:

move    #GRAF_MOUSE,control0
move    #1,control1
move    #1,control2
move    #1,control3
clr     control4
move    #ARROW,int_in0
clr.l   addr_in0
jsr     aes

The first five lines initialize the control array, giving 
the function number and the lengths of the int_in, int_out, 
addr_in, and addr_out arrays, as always. In the sixth line, 
we place the code for the arrow pointer form into *int_in0*. 
The array element *int_in0* must contain a value from Table 

Number  Shape
0               Arrow
1               I-beam
2               Bee
3               Pointing hand
4               Flat hand
5               Thin crosshairs
6               Thick crosshairs
7               Outline crosshairs
255             User-defined form
256             Mouse off
257             Mouse on

Table 3.1: Mouse Forms

Right now, you need be concerned only with the values 0 
through 7 in the table. We won't be discussing the others 
until later. Just realize that all you need to do to change 
the mouse form in the sample program is to replace the 
#ARROW (which equals 0) with any other number from 0 to 7 in 
the chart. Try it!
	In the last line of the *graf_mouse* call, we place a 0 
in *addr_in0*. When all we're doing is changing the mouse to 
one of the eight standard forms, this value will always be a 
0. When we learn about user-defined mouse forms, we'll be 
placing the address of our custom forms in *addr_in0*.
	After setting up the required arrays, we call 
*graf_mouse* just like any other AES function, with a call 
to our *aes* subroutine, after which *int_out0* will contain 
an error status code: 0 if an error occurred or a value 
greater than 0 if there was no error. Since it's extremely 
unlikely that we'll get an error when using the system mouse 
forms, we don't bother checking for an error in the sample 

--Loading a Resource File--

Next, we need to load our resource file--the one containing 
our menu--into memory. We do that with a call to the AES 
function #110, *rsrc_load*. The code looks like this:

move    #RSRC_LOAD,control0
clr     control1
move    #1,control2
move    #1,control3
clr     control4
move.l  #rsrc_file,addr_in0
jsr     aes

As always, in the first five lines, we initialize the 
control array. You should be very familiar with this process 
by now, since every call to the AES requires the control 
array. After taking care of the control array, we move the 
address of our resource filename into *addr_in0*. If you 
look in the data section of our program, you'll see that the 
label *rsrc_file* holds the address of the filename 
"MENU.RSC." A call to our *aes* subroutine is all that's 
necessary to get GEM to find the resource file and load it 
into memory--as long as the resource file is in the same 
directory as the program file, where it belongs.
	After the call, *int_out0* will contain a 0 if there 
was an error or a value greater than 0 if no error occurred. 
In the program, we use the instruction *tst int_out0* to 
check for an error. If we discover an error occurred, we 
display an alert box to the user and then exit the program. 
After all, our program won't work without the resource 
loaded. An error here probably means that the resource file 
is missing.
	Note that, to simplify showing error messages, the 
sample program includes a handy *alert* macro. You learned 
about macros in *The ST Assembly Language Workshop, Volume 
1*, and you used alert boxes a few pages ago, so you should 
have little difficulty understanding this simple macro.

--Getting the Resource's Address--

You may think that loading the resource is enough to get us 
into business, but it's not. Next, we must ask GEM for the 
resource's address, since many functions we'll be using in 
the program require this address. We get the address with a 
call to AES function #112, *rsrc_gaddr*. The code looks like 

move    #RSRC_GADDR,control0
move    #2,control1
move    #1,control2
clr     control3
move    #1,control4
move    #R_TREE,int_in0
move    #TREE00,int_in1
jsr     aes

In the first five lines, we initialize the control array. 
Then we place the code number for the type of data in our 
resource. This value must be one of those given in Table 

Number  Structure Type
0               Tree
1               OBJECT
2               TEDINFO
3               ICONBLK
4               BITBLK
5               String
6               Image data
7               obspec
8               te_ptext
9               te_ptmplt
10              te_pvalid
11              ib_pmask
12              ib_pdata
13              ib_ptext
14              bi_pdata
15              ad_frstr
16              ad_frimg

Table 3.2: Data Numbers

Yeah, I know how you're feeling. Table 3.2 looks downright 
scary. But don't let it bother you. At this point, you need 
be concerned only with the first code in the table. In fact, 
most resources you'll load in your programs will need only 
this first value.
	Finally, we must place into *int_in1* the index of the 
data structure we need the address for. This can be a bit 
confusing, too, and is something else we'll discuss in more 
detail later. Suffice it to say that a resource file is 
really an array of "objects." In our resource file, we have 
only one object, our menu. But despite the number of objects 
in our resources, we'll usually want the address of the 
entire resource. In the case of our menu, this index is 
represented by the constant TREE00, which was created by the 
resource construction program and placed into our MENU.H 
header file.
	Finally, we call our *aes* subroutine, which in turn 
calls *rsrc_gaddr* for us, using the arrays we set up. After 
the call, *int_out0* will contain a 0 if an error occurred 
or a value greater than 0 if no error occurred. More 
importantly, *addr_out0* will contain the address for which 
we are looking. In the sample program, if we don't get an 
error, we copy this address into the long word *menu_adr*, 
for safe keeping.

--Showing a Menu Bar--

Now that we have our resource file loaded, and we have its 
address, we can put our menu bar on the screen. We do this 
with a call to AES function #30, *menu_bar*, like this:

move    #MENU_BAR,control0
move    #1,control1
move    #1,control2
move    #1,control3
clr     control4
move    #1,int_in0
move.l  menu_,addr_in0  
jsr     aes

To call this function, we first set up the control array 
with the appropriate values. Then we place a 1 into 
*int_in0*. This is a flag that tells *menu_bar* that we want 
to show the menu. Finally, we put the address of our 
resource into *addr_in0* and call our *aes* subroutine. 
After the call, *int_out0* will contain a 0 if an error 
occurred or a value greater than 0 if no error occurred. If 
there was no error, the menu bar will be on the screen, as 
shown in figure 3.1.


--Getting Event Messages--

Our GEM programs are event driven. This means that, rather 
than force the user to do things in a specific preset order, 
we allow him to do whatever he wants. In other words, we can 
never be sure what the user is going to do. For example, now 
that we have a menu bar on the screen, the user may try to 
select menu functions with his keyboard or he may try to use 
his mouse. If we also had a window on the screen, the user 
may opt to manipulate the window before he uses the menu bar  
We just don't know what he'll do. This means that we must 
keep an eye out for his every action.
	GEM handles this seemingly impossible task by sending 
messages to our program. Whenever the user does something, 
he generates an event that GEM passes on to us. We won't go 
into too much detail about events in this chapter. We'll 
cover only what we need to know in order to handle a menu 
bar. But in upcoming chapters we'll use events a lot.
	Obviously, if GEM is going to be sending us 
information--in this case an event message--we need a place 
to store it. GEM stores this information in an event buffer, 
a 16-byte array that we must supply. If you look at the data 
section of this chapter's program, you'll see our message 
buffer. It looks like this:

msgbuf0:    ds.w    1
msgbuf1:    ds.w    1
msgbuf2:    ds.w    1
msgbuf3:    ds.w    1
msgbuf4:    ds.w    1
msgbuf5:    ds.w    1
msgbuf6:    ds.w    1
msgbuf7:    ds.w    1

When we ask GEM for event messages, we also tell it where 
our message buffer is. When GEM returns the message, it 
places the type of message in *msgbuf0* and other 
information about the specific message in the rest of the 
buffer. What this other information is depends on the type 
of message being returned. Table 3.3 shows the contents of a 
typical GEM message.

Element    Meaning
 0          Message ID
 1          ID of sending application
 2          Additional bytes in message
3-7         Changes with message type

Table 3.3: Contents of Message Buffer

	Element 2 of the message buffer requires explanation. 
Although the standard GEM message is 16 bytes long, it is 
possible for us to construct our own messages, which may be 
longer than the 16-byte standard. When constructing this 
type of message, we place the number of extra bytes in 
element 2 of the message buffer. But don't worry about these 
custom messages; we're a long way from discussing them--a 
long way, indeed.
	So, the next thing we must do is tell GEM to start 
sending us messages. That's the only way we'll know that the 
user has done something with our menu bar. In most full-
scale programs, we'd use a function called *evnt_multi*, but 
this function is so unwieldy (it has almost two dozen 
parameters!), that I thought it best if we opted for 
something simpler. For now, we'll start getting messages 
with a call to the AES function #23, *evnt_mesag*. That call 
looks like this:

move    #EVNT_MESAG,control0
clr     control1
move    #1,control2
move    #1,control3
clr     control4
move.l  #msgbuf,addr_in0        
jsr     aes

As you can see, the only information we need to give this 
function is the address of our message buffer, which we 
place in *addr_in0*. After the call, *int_out0* will contain 
a 1, a value that really means nothing, since it's always a 
1. More importantly, when the function returns, our message 
buffer will contain an event message, of which there are 
over a dozen types. In this chapter, we're concerned with 
only one type, the MN_SELECTED message, which has a value of 
10. In other words, if *msgbuf0* is a 10 after the call to 
*evnt_mesag*, we know the user has done something with the 

--Translating a Message--

When we call *evnt_mesag*, our program stops executing, 
while *evnt_mesag* waits for the user to do something. When 
the user does anything, such as clicking the mouse or typing 
on the keyboard, *evnt_mesag* sends us a message that tells 
us what the user did. As I mentioned previously, there are 
over a dozen different types of messages, but right now 
we're interested only in the MN_SELECTED message. With this 
message, GEM places the menu ID of the selected menu name in 
*msgbuf3* and the ID of the selected menu item in *msgbuf4*.
	To see what type of message our program received, we 
must examine the first element of the message buffer, in our 
case *msgbuf0*. We do this with these instructions:

cmpi    #MN_SELECTED,msgbuf0
bne     event_loop

The above instructions first compare the constant 
MN_SELECTED to the value returned into *msgbuf0* by our call 
to *evnt_mesag*. Then, if we didn't get a MN_SELECTED 
message, the second line sends program execution back to 
grab another message. This loop continues until we find a 
MN_SELECTED message.
	When we finally receive a MN_SELECTED message, we know 
that the user has selected a command from our menu bar. The 
next step is to figure out which command the user selected. 
We do this by checking the menu selection's ID, which is 
returned in *msgbuf4* as part of the message. In the sample 
program, we have set up a table of menu IDs. You can see 
this table in the data area, at the label *menu_ids*. We 
loop through this table, looking for the menu ID that the 
user selected. When we find it, we use its position in the 
table to find the address of the routine to which we need to 
jump in order to handle the user's request.
	In other words, if the user selects the Quit command on 
the menu, our program finds that the QUIT ID is in element 4 
of the *menu_ids* table. So, the program loads into A6 the 
address stored in the fourth element of the *menu_vecs* 
array. If you look at the *menu_vecs* array, you'll see that 
this element is the address of the *quit* section of the 
program. (Remember: by putting labels into a table, we're 
really adding the addresses the labels represent to the 
table. The *menu_ids* table, therefore, contains the 
addresses of all the routines that handle our menu's 
	When we have the address that we need in A6, we use 
address register indirect addressing to jump to that 
address, like this:

jmp    (a6)

The *jmp* instruction is used to transfer program execution 
to an effective address. It works a lot like the *bsr* and 
*jsr* instructions, but doesn't load a return address onto 
the stack. In other words, a *jmp* is like a GOTO in BASIC, 
rather than like a GOSUB.
	In the case of the info, load, save, select1, select2, 
and select3 menu selections, all we do is show the user an 
alert box, confirming that his menu selection was received. 
In a real program, of course, we'd need to do a lot more. 
The real fun starts when the user selects one of the other 
menu items.

--Menus Items and Checkmarks--

For example, the entries in the Options menu must be checked 
or unchecked whenever the user clicks on one. To do this, we 
first must know the state of the selected menu item. We keep 
track of each option's state with three flags: *optn1*, 
*optn2*, and *optn3*. A flag value of 0 means that the menu 
item is unchecked; a value of 1 means the menu item is 
	Let's say the user clicks on Option 1, which, in the 
sample program, starts off with a checkmark, as shown in 
figure 3.2. Here's the code that handles that situation:

	tst    optn1
	beq    setcheck1
	clr    optn1   
	clr    check_flag
	bra    check
	move   #1,optn1        
	move   #1,check_flag
	bra    check


First, we check the flag for the Option 1 menu item with the 
*tst* instruction. If that flag is a 0, we jump to the label 
*setcheck1*, where we change the *optn1* flag to true (1) 
and also initialize *check_flag* to true. We'll use 
*check_flag* in our call to the AES function that displays 
or removes checkmarks.
	If, as is true in our sample program, *optn1* is equal 
to 1, we set both *optn1* and *check_flag* to 0, indicating 
that we're about to turn the checkmark off.
	Finally after setting up our flags, we branch to the 
label *check*, where we actually add or remove the 
checkmark. That code looks like this:

      move    #MENU_ICHECK,control0
      move    #2,control1
      move    #1,control2
      move    #1,control3
      clr     control4
      move    msgbuf4,int_in0 
      move    check_flag,int_in1      
      move.l  menu_adr,addr_in0       
     jsr      aes

This is a call to AES function #31, *menu_icheck*, which 
adds or removes checkmarks to and from menu items. After 
setting up the control array, we place the menu item ID into 
*int_in0*, the flag value into *int_in1*, and the address of 
our resource into *addr_in0*. If the value in *int_in1* is 
0, *menu_icheck* will remove the menu item's checkmark; if 
the value is 1, *menu_icheck* will add a checkmark to the 
item. After the call, *int_out0* will contain a 0 if an 
error occurred or a value greater than 0 if no error 

--Unhighlighting a Menu Name--

When GEM receives a menu message, it automatically 
highlights the menu name on the menu bar, as seen in figure 
3.3. What it doesn't do is set the menu name back to normal 
text. This is the programmer's job, since GEM assumes that 
you want the menu name to stay highlighted until you're 
through handling the user's request (a safe assumption).


	When we're ready to unhighlight the menu's name, we 
need only call AES function #33, *menu_tnormal*. Because we 
need to call this function after every menu message, it 
seems logical to make the call into a subroutine, which 
we've done in the sample program. Here's what that 
subroutine looks like:

move    #MENU_TNORMAL,control0
move    #2,control1
move    #1,control2
move    #1,control3
clr     control4
move    msgbuf3,int_in  0
move    #NORMAL,int_in1
move.l  menu_adr,addr_in0       
jsr     aes

After setting up the control array, we place the ID of the 
menu name to unhighlight in *int_in0*, a flag telling the 
function whether to highlight or unhighlight the menu 
(0=highlight, 1=unhighlight) into *int_in1*, and the address 
of the resource containing the menu into *addr_in0*. After 
the call, *int_out0* will contain a 0 if an error occurred 
or a value greater than 0 if no error occurred.

--Enabling and Disabling Menu Entries--

When the user clicks the Off selection of the Selects menu, 
we have much work to do. First, we must disable all the 
commands in the bottom part of the menu. Then we must change 
the string "Off" in the menu to read "on," since this menu 
selection should tell the user what the command does. These 
changes are shown in figure 3.4.


	To disable a menu selection, we use a call to AES 
function #32, *menu_ienable*. In our program, that call 
looks like this:

move    #MENU_IENABLE,control0
move    #2,control1
move    #1,control2
move    #1,control3
clr     control4
move    d6,int_in0
move    on,int_in1
move.l  menu_adr,addr_in0       
jsr     aes

As always, we start by setting up the control array. Then, 
we place the ID of the menu item we want to disable into 
*int_in0*, the setting code into *int_in1*, and the address 
of our resource into *addr_in0*. In the example above, D6 
holds the menu item ID, while the flag *on* holds the 
setting code, which should be 0 to disable a menu item or a 
1 to enable it. After this call, *int_out0* will contain a 0 
if an error occurred or a value greater than 0 if no error 
	To disable all the menu items below the ONOFF menu 
item, we must call *menu_ienable* once for each. To simplify 
this, we use a loop, with register D6 containing the menu 
item ID we want to disable. Each time through the loop 
(which starts at the label *onoff*), we increment D6. 
Obviously, this technique will work only if the three menu 
item IDs are in consecutive order.

--Changing a Menu String--

After we've disabled the menu entries, we need to change the 
string in the ONOFF menu entry to "On," indicating that, if 
the user clicks on it, the menu items will be turned on. We 
do this change with a call to AES function #34, *menu_text*, 
which looks like this:

move    #MENU_TEXT,control0
move    #1,control1
move    #1,control2
move    #2,control3
clr     control4
move    #ONOFF,int_in0  
move.l  menu_adr,addr_in0       
move.l  a5,addr_in1     
jsr     aes

First, we set up the control array. Then we place the menu 
item ID of the item we want to change into *int_in0*, the 
address of the resource into *addr_in0*, and the address of 
the replacement string into *addr_in1*. Note that the new 
string must not be larger than the original string. If it 
is, you may find that the new string overflows the menu, as 
shown in figure 3.5. The strings we use for the menu in the 
sample program are found in the data section at the labels 
*off_str* and *on_str*.


--Removing a Menu Bar--

Eventually, the program's user is going to click on the 
menu's Quit selection. When he does, we need to remove the 
menu from the screen in preparation for shutting down the 
program. To remove a menu from the screen, we use another 
call to AES function #30, *menu_bar*. That call looks like 

move    #MENU_BAR,control0
move    #1,control1
move    #1,control2
move    #1,control3
clr     control4
clr     int_in0 
move.l  menu_adr,addr_in0       
jsr     aes

This call is identical to the one we used to display the 
menu, except we're placing a 0 in *int_in0*, which tells the 
function to remove the menu, rather than a 1, which tells 
the function to create the menu.

--Releasing a Resource--

Before we can exit the program, we have one last bit of 
clean-up we need to do. Because we loaded a resource into 
the computer's memory, we have to tell GEM that it's okay to 
use that memory for something else. We do this with a call 
to AES function #111, *rsrc_free*. Our call to this function 
looks like this:

move    #RSRC_FREE,control0
clr     control1
move    #1,control2
clr     control3
clr     control4
jsr     aes

This call requires no parameters from us. All we need do is 
set up the control array and call our *aes* subroutine. 
After the call, *int_out0* will contain a 0 if an error 
occurred or a value greater than 0 if no error occurred.
	After releasing the resource's memory, we're all clear 
to end the program, with the usual call to *pterm0*.


While handling a menu isn't too complex in theory, it does 
require a great deal of code, as you can tell from this 
chapter's program. This is typical of GEM, which, in order 
to provide extra convenience for the user, heaps the 
programmer with additional responsibilities. But that's 
really as it should be. The user should always be the first 


* GEM menus and dialogs, as well as other types of GEM 
objects, are stored in a resource file.

* The easiest way to create a resource file is to use a 
resource construction program.

* AES function #78, *graf_mouse*, is used to change the 
shape of the mouse pointer, among other things.

* Before GEM resources can be displayed on the screen, their 
resource file must be loaded into memory. This is done with 
AES function #110, *rsrc_load*.

* After a resource is loaded, the program needs to know its 
address. This address is retrieved using AES function #112, 

* AES function #30, *menu_bar*, displays or removes a menu 

* GEM tells an application about its user's activities 
through messages, which are 16-byte records stored in a 
message buffer that the programmer supplies.

* AES function #23, *evnt_mesag*, is one way to retrieve 
messages from GEM.

* AES function #31, *menu_icheck*, adds or removes 
checkmarks from a menu item.

* AES function #33, *menu_tnormal*, highlights or 
unhighlights a menu name on the menu bar.

* AES function #32, *menu_ienable*, enables or disables 
(grays out) menu items.

* AES function #34, *menu_text*, changes the string 
displayed in a menu item.

* AES function #111, *rsrc_free*, releases the memory 
occupied by a resource.

CW_MENU.H (Source of the chapiter)
CW_PROG3MAC.S (Source of the chapiter)
CW_PROG3.S (Source of the chapiter)

Back to Assembly_language_tutorials

Personal tools