Window Structures
Volume Number: 5
Issue Number: 6
Column Tag: abC
Related Info: Window Manager
By Bob Gordon, Minneapolis, MN
Welcome to the second incarnation of the MacTutor intro column. The column is
called abC because of its introductory nature (the “abc’s”), and it uses the C language
(the “C”). What I propose to do is to continue in the spirit of the previous set of
articles, but focus less on C and more on the Mac.
I also will not attempt to present a complete program each time. Since an
introduction by its very nature tends to be a bit repetitive, I found the last time that
the same code would appear for months at a time. This took up a lot of space in the
magazine, and made it difficult to focus on one issue as we were always carrying around
a large amount of other code just to make an application work. This means that the
articles will tend to be shorter, which will likely make it more possible for me to get
them done.
One other point before we start. I found that one of the most useful things in
writing for MacTutor is getting mail. Feel free to write; comments are much
appreciated; and include your phone number.
Making a Window
One of the first steps in a Mac application is putting a window on the screen,
typically in response to a request from the user. This method developed here is done
entirely in code (as opposed to using resources). This has some limits, but offers the
ability to easily add some features to ease the maintenance of windows.
There are two points: First a window consists of the window stuff and the
application specific stuff. From the Mac’s point of view, the window stuff consists of
only the frame and does not even include the scroll bars (if any). On the other hand the
application probably does not want to be concerned with such things as the scroll bars,
zoom boxes, sizing, et cetera.
Second, it is good programming practice to separate the application specific code
from the more generic user-interface code. This eases maintenance and debugging and
modification. To this end I created a file, shell.c which handles many of the generic
properties, helper files (e.g. windowhelp.c) to add the capabilities I wanted, and the
file app.c, which actually contains the parts of the application. In the snippets of code
that follow, you will notice an occasional call to a function like appxxx(). This is a call
in the shell part of the program to the app.c file. It is here, after, for example,
preparation has been made for updating a window (appupdate() ), that the application
must update the application portion.
windowhelp.h
The windowhelp functions work because the WindowRecord defined in the ToolBox
is a fixed length object. What I did is add some additional data structures on the end.
This simply makes the object a little longer, but all the toolbox window and QuickDraw
functions will work correctly. The advantage of doing this is that I can now keep
additional information, which I think should be attached to a window in a safe place
where I can always find it, and the application parts of the code need to concern
themselves with it.
One might suggest that the WRefCon (a field in the WindowRecord specifically for
the application’s own use) field is the proper place for this. This is probably true, but
so much of this stuff seemed to either be more part of the window than the application
(scroll bars) or likely to be part of any application (knowing whether the contents had
changed or not), that it seemed a Good Idea to put it all together in one place. In this
way much of the Mac user interface is handled for us each time we start a project. I use
the WRefCon field to store the reference to the applications information proper.
Now, I make have no pretenses that this is the optimal way of doing things. In
fact, I know there are additions and changes I am going to make, but if we wait to get all
that worked out, we’ll never get this written.
A few comments about the fields:
The first four are what I call window margins. I noticed that many applications
place various graphic objects around the edges of the window. There are scroll bars to
the bottom and right, rulers on the top and tools on the left. Whatever it is, it brings in
the edge of the window as far where the application can write. The window margins are
sizes, in pixels of the areas reserved by things around the edges. The application can
change them (if the user asks to see the rulers, for example).
The next field, cursrt, is the rectangle defined by the window and the margins. I
called it cursrt because outside the rectangle the cursor is typically the 11 o’clock
arrow, and inside the cursor is whatever the application would like.