Menus and Windows in LightSpeed C

By Bob Gordon, Apropos Publications, Contributing Editor

An easy to follow user interface is one component of good quality software. On the Macintosh, the design of the user interface is largely laid out for us. Use windows and menus. Last month, we used control keys to place a single window on the screen and make some modifications to it. This month we will do the same thing but use menus rather than control keys. You will notice that this month's program is very similar to last month's. There are some obvious differences from the addition of menus and some less obvious differences because I used a different compiler. Since the program contains functions from last month, we'll tie up a few loose ends, and cover a basic C concept as well.

C Assignment Statements

The assignment statement is probably the most basic statement in most languages. I don't think I've used it yet in any of these programs because we have done very little arithmetic. Since it is so basic, we'll go over it this month.

The C assignment operator is the equal sign:

 x = 7;
 y = a + b;
 z = max(x,y);

The effect of the assignment operator is to take the value of the right hand side and place in the variable on the left hand side.

With most languages, this would be about as much as we would say. C, however, also offers a set of specialized assignment operators. These apply when the variable on the left is also on the right as in:

 x = x + 1; /* increment x  by 1 */

The preferred C form is:

 x += 1;/* increment x by 1 */

This is a bit easier to follow as it is obvious that what we want to do is increment x. It would also be obvious to the compiler, which may generate more efficient code.

Here is a list of all the C assignment operators.

= assignment

+= addition assignment

-= subtraction assignment

*= multiplication assignment

/= division assignment

%= modulus assignment

>>= shift right assignment

<<= shift left assignment

&= bitwise AND assignment

|= bitwise inclusive OR

^= bitwise exclusive OR

The first three are the most frequently used, but you may run across another. Don't be too surprised when you see one.

Cleaning Up the Windows

There is one point from last months program about windows that deserve some clarification: The use of the "cast" in the call to NewWindow(). Each parameter of a function has to receive the correct type. C does not do type checking on external functions, and passing the wrong type can yield disastrous results. NewWindow() expects a WindowPtr for its behind parameter (specifies an existing window to place the new window behind). If the new window should be in front of all the other windows behind receives a minus one, but the minus one must be a window pointer.

To change the type of an object a cast is used. Place the type name in parentheses before the object you wish to change. The effect is as if there were a new variable of the proper type to which you assigned the orignal object. The original object is unchanged. It is preferrable to use a cast rather than an integer or long because the internal representation of an integer or long may not be the same as that of a pointer. So, to change minus one to a WindowPtr, do:

(WindowPtr)-1

This will ensure that the parameter is not only of the same size, but of the correct type as well.

LightspeedC

Since this column is devoted to learning to program in C on the Macintosh, I have been on the lookout for tools that will facilitate the learning process. LightspeedC is such a tool. Its major advantages from our point of view is that it is very fast at compiling and linking and that it places you at the correct position in your source file if the compiler detects an error. The result is that you can edit, compile, link, and run your program very rapidly, make small variations in the code and determine their effect, and generally have the opportunity to make more mistakes in a shorter period of time. If we learn from our mistakes, Lightspeed C is a useful tool for learning C on the Macintosh.

LightspeedC is different from the other available C compilers as it does not use a Unix-like setting [Yea! -Ed.] -nor does it use separate programs in the Macintosh window environment. Instead it creates its own enviornment (that follows the Macintosh User Interface) from which all editing, compiling, linking, and running take place. The integrated editor is roughly similar to the Edit application. Menus available from inside the editor allow you to run, compile, or just check the syntax. As soon as the compiler detects an error, you are returned to the editor with the cursor at the location the compiler found the error. In other words, you get one error at a time.

The link operation is extremely fast. With this month's small program, I often did not notice the link had happened. If you choose the run option from the editor, it will compile, link, and launch your program. When you quit your program, the LightspeedC environment reloads, and you can continue.

The key to the speed seems to be the system's use of a project. The necessary files are installed into the project, and I guess much of the linking takes place at intallation or compile time. The project also provides a make facility-it keeps track of changes in source, include, and library files, and recompiles them as necessary.

I came across a few problems in using LightspeedC. First, it follows the proposed ANSI standard for passing structures as parameters. As I mentioned last month, C traditionally only allowed passing pointers to structures and this complicates the passing of the Macintosh Point type (which is a four byte structure that the Mac expects to find passed by value rather than by reference). LightspeedC passes a Point correctly by value. This is not a problem except it took me over an hour to realize what was going on. I wrote the menu program under Mac C first, and then installed the source in Lightspeed.

A second problem is that Lightspeed does not include the QD variable we used last month to obtain the size of the screen. You will note in this month's program that the dragbound rectangle (which describes the limits for dragging a window) and the limit rectangle (which set the maximum size to which a window may grow) are set with hard coded numbers.

A more serious problem is that there is no way to easily print to the screen in the Macintosh environment. (LightspeedC includes printf() as well as a number of other Unix-type output functions, but the use of any of these invokes a Unix environment that eliminates the menu bar and windows. Since I was trying to debug a problem with windows, this was not at all useful. By the way, LightspeedC includes one of the larger collection of Unix compatible functions in its libraries.) Not having a printf() like routine for the Mac environment considerably reduces the usefulness of LightspeedC as a learning tool. [Too bad. They could use an assembler too! -Ed.]

The manual that comes with the package is a large format paperback. About a third of its pages are devoted to a description of all the Unix compatible functions. (Many of these, such as the string functions, are useful in the Macintosh environment. Whether such things as the memory management and file handling routines are useful would depend on whether they invoke the Unix environment and whether you wish to port your program off the Macintosh.) The descriptions of the Macintosh functions are limited to listing the name and calling sequence in the order they appear in Inside Macintosh. Alphabetical order would have been better. [Why is it developers keep slighting the Mac toolbox in their documentation? -Ed.]

Finally, Lightspeed uses different names for its header files There is no standard so this is not a problem. Since I moved the code to Lightspeed from Mac C, it would not compile immediately. I decided to change the names of the header files so they would look familiar to most people.

In general I am very impressed with the package as a learning environment. The fact that it generates fast, compact code (a fact I have not verified) is simply a bonus.

C What's on the Menu

This program does the same thing last month's program did except it's control is through menus. There is one additional visible (to the user) feature: an item in the File menu will add a new menu called Test. The Test menu allows items to be checked. The comments in the code describe other differences. I'll describe each function briefly.

main()

Main has basically disappeared. It simply calls two initialization functions. I prefer to keep the system initialization separate from the application. Eventually we'll have everything we need in the system application and will not have to change it.

initsys()

Initializes system stuff. If you compare the initialization this month with last month's, you will notice the first two lines were not in last time. They are handled automatically by Mac C.

initapp()

Sets up the menus. AppendMenu() adds the menu string(s) to the menu; InserMenu() adds the menu to the menu bar. Notice the string in the calls to AppendMenu(). It contains several metacharacters as Inside Macintosh calls them. They control the display and sometimes the operation of the menu items.

Meta Characters Explained

Character Meaning

; Separates items (can also use return)

^ Item has an icon; followed by icon number

! Item is marked with following character

< Item is in special style, followed by B, I, U, O, or S

/ Item has keyboard equivalent, followed by the character

( Item is disabled

eventloop()

An event loop like we have seen before. The test on theWindow at the begining enables/disables the items in the File menu to open/close the window. The disabled items are in gray. We probably should disable the Apple menu because we don't support Desk Accessories. Other items in other menus should switch as well. You might try to add these features.

Notice the special handling of keyDown events. In case of keyDown, the modifers field is checked for the command key being down. If the command key is down, MenuKey() is used to generate the same code as MenuSelect(), and the code is passed to domenu(). This is how command keys work with menus. You might want to add some more command keys to the menus.

domouse()

This is almost identical to last month's. The only difference is that here we call domenu() if the mouse is in the menu bar. Remember to handle er->where correctly for your compiler.

domenu()

This is simply a switch. The menu code consists of two components packed into a long. HiWord() and LoWord() are two Toolbox functions that extract the lower and upper words of a long.

dofile()

Contains the code to handle the File menu. Note cases five and six. They contain a call to DrawMenuBar() because they change the menu bar. Any changes do not appear until the menu bar is redrawn.

dowind()

Handles the Window menu. Add DisableItem() and EnableItem() calls to this one.

dotest()

This does not do anything except mark and unmark the items.

The Program

/* menu and window manager demonstration 
 * base on program in 
 * Using Macintosh Toolbox with C
 * page 91
 *
 * Compiled with LightspeedC
 *
 * Important note for Mac C users:
 * Everyplace you see event->where,
 * replace it with &event->where
 */
 
 
 #include "abc.h"/* our own header, see last month */
 #include "Events.h"
 #include "Window.h"
 #include "Menu.h"
 
 /* defines for menu ID's */
 
 #defineMdesk    100
 #defineMfile    101
 #defineMedit    102
 #defineMwind    103
 #defineMtest    104
 
 /* Global variables */
 
 MenuHandle menuDesk;/* menu handles */
 MenuHandle menuFile;
 MenuHandle menuEdit;
 MenuHandle menuWind;
 MenuHandle menuTest;
 
 
 WindowPtrtheWindow;
 WindowRecord  windowRec;
 Rect   dragbound;
 Rect   limitRect;
 
main()
{
 initsys(); /* system initialization */
 initapp(); /* application initialization */
 eventloop();  /* Do it! */
}


/* system initialization 
 * note use of hard coded screen sizes
 * with LightspeedC.  This will work
 * with other compilers but is not
 * good practice
 */
initsys() 
{
 InitGraf(&thePort); /* these two lines done */
 InitFonts();    /* automatically by Mac C */
 InitWindows();
 InitCursor();
 InitMenus();
 theWindow = Nil;/*indicates no window */
 SetRect(&dragbound,0,0,512,342);
 SetRect(&limitRect,60,40,508,318);
}


/*
 * application initialization
 * Sets up menus.
 * Each menu is a separate group
 * of lines.  Note the last menu
 * is appended but not inserted.  This
 * makes it part of the menu list but 
 * not in the menu bar.
 */
initapp()
{
 menuDesk = NewMenu(Mdesk,CtoPstr("\24"));
 AddResMenu (menuDesk, 'DRVR');
 InsertMenu (menuDesk, 0);
 
 menuFile = NewMenu(Mfile, CtoPstr("File"));
 AppendMenu (menuFile, 
 CtoPstr("Open Window/M;Close Window/X;Quit/Q"));
 AppendMenu (menuFile, 
 CtoPstr("(-;Show Test;(Hide Test"));
 InsertMenu (menuFile, 0);
 
 menuEdit = NewMenu(Medit, CtoPstr("Edit"));
 AppendMenu (menuEdit, 
 CtoPstr("Undo;(-;Cut;Copy;Paste;Clear"));
 InsertMenu (menuEdit, 0);
 
 menuWind = NewMenu(Mwind, CtoPstr("Window"));
 AppendMenu (menuWind, 
 CtoPstr("Hide;Show;New Title"));
 InsertMenu (menuWind, 0);
 
 menuTest = NewMenu(Mtest, CtoPstr("Test"));
 AppendMenu (menuTest, 
 CtoPstr("Pick;One;Of;These"));
 
 DrawMenuBar();
}
 
 
/* Event Loop 
 * Loop forever until Quit
 */
eventloop()
{
 EventRecordtheEvent;
 char   c;
 short  windowcode;
 WindowPtrww;
 
 while(True)
 {
 if (theWindow)      /* this code is here to */
 { /* prevent closing an */
 EnableItem(menuFile,2);  /* a closed window */
 DisableItem(menuFile,1);
 }
 else   
 { 
 EnableItem(menuFile,1);
 DisableItem(menuFile,2);
 }
 
 if (GetNextEvent(everyEvent,&theEvent))
 switch(theEvent.what)    
 
 { /* only check key and */
 case keyDown:   /* mouse down events */
 if (theEvent.modifiers & cmdKey)
 {
 c = theEvent.message & charCodeMask;
 domenu(MenuKey(c));
 }
 break;
 case mouseDown:
 domouse(&theEvent);
 break;
 default:
 break;
 }
 }
}


/* domouse
 * handle mouse down events
 */
domouse(er)
 EventRecord*er;
{
 short  windowcode;
 WindowPtrwhichWindow;
 short  ingo;
 long   size;
 
 windowcode = FindWindow(er->where, 
 &whichWindow);
 switch (windowcode)
 {
 case inDesk:
 if (theWindow notequal 0)
 {
 HiliteWindow(theWindow, False);
 DrawGrowIcon(theWindow);
 }
 break;
 case inMenuBar:
 domenu(MenuSelect(er->where));
 break;
 case inSysWindow:
 SysBeep(1);
 break;
 case inContent:
 HiliteWindow(whichWindow,True);
 DrawGrowIcon(theWindow);
 break;
 case inDrag:
 DragWindow(whichWindow, 
   er->where, &dragbound);
 DrawGrowIcon(theWindow);
 break;
 case inGrow:
 /* not included this month */
 break;
 case inGoAway:
 ingo = TrackGoAway(whichWindow,er->where);
 if (ingo)
 {
 CloseWindow(whichWindow);
 theWindow = Nil;
 }
 break;
 }
}

/* domenu
 * handles menu activity
 * simply a dispatcher for each
 * menu.
 */
domenu(mc)
 long   mc; /* menu result */
{
 short  menuId;
 short  menuitem;
 
 menuId = HiWord(mc);
 menuitem = LoWord(mc);
 
 switch (menuId)
 {
 case Mdesk : break;
 /* not handling DA's */
 case Mfile : dofile(menuitem);
  break;
 case Medit : break;
 
 case Mwind : dowind(menuitem);
  break;
 case Mtest : dotest(menuitem);
  break;
 }
 HiliteMenu(0);
}

/* dofile
 * handles file menu
 */
dofile(item)
 short  item;
{
 char   *title1; /* first title for window */
 Rect   boundsRect;
 
switch (item)
 {
 case 1 : /* open the window */
 title1 = "ABC Window";
 SetRect(&boundsRect,50,50,300,150);
 theWindow = NewWindow(&windowRec, 
 &boundsRect,CtoPstr(title1),True,
 documentProc,(WindowPtr) -1, True, 0);
 DrawGrowIcon(theWindow);
 PtoCstr(title1);
 DisableItem(menuFile,1);
 EnableItem(menuFile,2);
 break;
 
 case 2 : /* close the window */
 CloseWindow(theWindow);
 theWindow = Nil;
 DisableItem(menuFile,2);
 EnableItem(menuFile,1);
 break;
 
 case 3 : /* Quit */
 ExitToShell();
 break;
 
 case 5 : /* Install additional menu */
 InsertMenu(menuTest,0);
 EnableItem(menuFile,6);
 DisableItem(menuFile,5);
 DrawMenuBar();
 break;
 
 case 6 : /* remove additional menu */
 DeleteMenu(Mtest);
 EnableItem(menuFile,5);
 DisableItem(menuFile,6);
 DrawMenuBar();
 break;
 
 }
}

/*
 * dowind
 * handles window menu 
 * Note that each case contains an
 * if testing the existance of the
 * window.  This could be written
 * with one if before the switch.
 */
dowind(item)
 short  item;
{
 char   *title2; /* second title for window */
 
 switch (item)
 {
 case 1 : /* Hide */
 if (theWindow)
 HideWindow(theWindow);
 break;
 case 2 : /* Show */
 if (theWindow)
 ShowWindow(theWindow);
 break;
 case 3 : /* Change title */
 if (theWindow)
 {
 title2 = "A Different Title";
 SetWTitle(theWindow, CtoPstr(title2));
 PtoCstr(title2);
 }
 break;
 }
}

/* dotest
 * Handles new menu.
 * All this does is mark menu
 * items if they are not marked and
 * unmark them if they are.
 */
dotest(item)
 short  item;
{
 short  mark;
 
 GetItemMark(menuTest,item,&mark);
 if (mark)
 CheckItem(menuTest,item,False);
 else
 CheckItem(menuTest,item,True);
}