MacApp Objects
Volume Number: 3
Issue Number: 9
Column Tag: MacApp Objects
Programming in the Closet
By David A. Wilson, Personal Concepts, Palo Alto, CA
or
“How to write a program without really writing a program”
Dave Wilson is the owner of Personal Concepts, a consulting firm specializing in
software development for the Macintosh. He currently is teaching courses for Apple on
both beginning Macintosh programming and object-oriented programming.
This article can be blamed on Howard Katz, who is the newsletter Editor for the
MacApp Developer’s Association. Howard knew that I present four-day Seminars for
Apple entitled MacApp™ and Object Oriented Programming , and thought that
experiences from the first five of these seminars might be useful to others who are
learning MacApp. Much of this article first appeared in the May 1987 issue of the
MacAppDA’s newsletter, and is reprinted with their permission. I might add that you
should definitely join us in the MacAppDA if you have an interest in object-oriented
programming for the Macintosh. You can join by sending $15.00 to:
MacApp Developer’s Association
P.O. Box 23
Everett, WA 98206-0023.
First, some background to put the article in perspective. I have taught Apple’s
beginning Macintosh Programming Seminars for the last two and one-half years, and
have developed a healthy respect for the difficulties of writing Mac applications during
this time. Starting about two years ago, I began to hear about this strange beast called
MacApp that was claimed to make Mac programing relatively easy, so I got a copy to try
out.
I didn’t begin seriously learning to use it until last Fall, when Apple agreed that a
monthly Seminar was needed to help people get up to speed quickly on this new and
powerful tool, so I started learning MacApp with more urgency. It took me about three
man-months to feel comfortable with it, and the seminar is designed to fit as much of
those experiences as possible into four days.
By the way, Apple also decided to provide a separate one-day seminar on Using
MPW the day before each MacApp class, so we could cover Make files, Rez, etc. before
worrying about MacApp itself. More about that below. By now you should be wondering
if I am ever going to explain the weird title, so here goes
A History Lesson
A long, long time ago, in an operating system far, far away, applications
programmers wrote code that directed the user along a certain path. As the
programmer, you were clearly in control of what happened, so you gave orders to the
user, and the user did what he or she was told. If the user did not follow orders, you
displayed friendly error message such as “Syntax Error 5”, and hoped the user would
shape up.
Then the Macintosh came along, and you were instructed to write friendly,
“modeless” programs, with the operation controlled by the user. (Incidentally,
humor writer Dave Barry defines “User” as the word that programmers use when
they mean “idiot”). You wrote modeless programs by basing your application on a
Main Event Loop. This had you calling the GetNextEvent ROM routine, and responding
accordingly to events caused by the user. I liken this to programming in a room with
the door closed. You can’t see the user, but when the user clicks the mouse down or
types a key, the Event Manager slides a piece of paper under the door that contains the
Event Record. You read the piece of paper, and respond accordingly.
Some programmers who are new to the Macintosh feel a bit nervous with this
style because they don’t feel in control, but users certainly prefer it - because they
are in control.
What happens with MacApp? It gets even worse. MacApp is an expandable generic
application, consisting of hundreds of pages of Object Pascal source code written by
some of Apple’s best programmers. All you have to do is customize the application
through the special hooks provided by object-oriented programming, and, presto: you
have your program!
Fig. 1 Getting into Objects in the Class Lab
Are you still all alone in the room, looking at pieces of paper slid under the door
by the Event Manager? Uh-uh, MacApp is. Where are you? You are in the closet.
Most of the time the program runs without needing your code at all, so MacApp will
handle moving and resizing windows, operating scroll bars, opening Desk Accessories,
etc. Once in a while MacApp needs you to do something specific to your program, so it
opens the closet door, barks at you to “Draw yourself” or “Save the data to disk”, and
then closes the door. You just do what your told, and stay out of the way the rest of the
time.
With MacApp, you are no longer writing an applications program, but rather you
are writing a few code fragments that customize the generic program written by Apple.
Apple’s code runs the Main Event Loop, and does most of the event handling, so be sure
to take a good book in the closet, because most of the time, you won’t have anything to
do.
Your only problem will be in learning to use MacApp, and getting used to this new
style of writing code. Which brings us
Back to the Seminars
Who takes these seminars? So far, we have had programmers from large
corporations and universities, independent developers, Apple systems engineers, and
Apple internal software developers. I expect to see many VARs (Value Added Resellers)
and consultants during the next year - particularly as the powerful Macintosh II
stimulates new interest in programming the Mac.
The MacApp seminar itself is a mixture of lectures and hands-on labs. We
probably spend about 25% of the first two days programming, and perhaps 50% of the
last two days. Each person has a Mac Plus with an HD-20 or HD-20SC with MPW and
MacApp installed to use during class. We also provide some new sample programs and
a 500-page Notebook.
The programming Labs begin with the Nothing program provided by Apple as a
standard MacApp sample. You then add features to this program over the next four days
until you have a text editor that, just for fun, can draw rectangles on top of the text. A
palette controls part of the program’s operation, and the text and graphics can be saved
to a document file on disk. This process is described in a 13-part exercise that you
work on for the whole four days - at your own pace. The majority of people will not
finish this project during class, but do leave with the “solution” on disk, so they can
finish it on their own if they wish. A screen dump from the finished Lab is shown
below in figure 1.
At this point, you might ask “Is MacApp easy to learn?”, and I would have to
answer a definite “maybe”. Perhaps 25% of the students so far find that they are
writing MacApp programs within four days. The other 75% find that they know much
more about MacApp, but still feel that they need to invest more time on their own
before they are ready to write a program. The major obstacle seems to be learning the
new style and behavior of object-oriented programming, so people who have had
experience with SmallTalk, Neon, Common LISP, etc. have a much easier time.
In the rest of this article, I’ll mention some of the common stumbling blocks, and
suggest ways around them. This article will be most useful to you if you have already
tried to learn MacApp on your own, and are having problems with understanding
certain concepts. If you have never seen MPW or MacApp, you might want to read