Tools Compared
Volume Number: 4
Issue Number: 10
Column Tag: Programmer's Tools
Prototyper, MacExpress & FaceIt Compared 
By Doug Poland, Niceville, FL
Three Programming Tools Compared
The purpose of this article is to review several programming tools that make the
job of providing your application with a Macintosh™ user-interface easier and
quicker. While there are many different products of this nature, I can only reasonably
discuss those products I have purchased and used.
This review deals with products that are procedural in implementation. An
alternative to these types of tools is the use of an object-oriented programming (OOP)
library as a starting point for your application. OOP is e specially attractive on the
Macintosh because of the strong visual metaphor utilized by its interface, and I would
encourage you to obtain as much information as possible if you are intrigued by OOP.
Producing a Macintosh Application
Since you probably spend a great deal of time using a Macintosh, you are no doubt
familiar with the minimum requirements of a good Macintosh application. Obviously,
the user-interface is the characteristic that distinguishes Macintosh applications from
other computer programs. In general, your application should support the
user-interface (as described by Apple) to the extent reasonable, including the
clipboard, file operations, desk accessories, printing and support the latest system
software.
Implementing this type of interface is no small task. I would estimate that in a
typical commercial application, as many as 5000-10000 lines of code are dedicated to
supporting the features described above. Many programmers turn, at least in part, to
previously written libraries of code or commercial application shells to accomplish
this task.
This article discusses three products that address this need in varying degrees.
The advantage of using these products is that they contain a great deal of “accumulated
programming knowledge” related to implementing the Macintosh user interface and
are excellent starting points for your application.
While the choice of a particular programming language is largely a function of
which you are most comfortable with, some languages are better supported by
programming tools than others and, in general, a compiled language is the best choice
for a commercial application.
Pascal probably has the largest selection of programming tools, but C, Assembly
and Modula-2 (to name a few) are popular languages for the Macintosh that are
supported by application “shells”. Fortran, an excellent engineering language, is not
supported by many programming tools. However, as you will see, it is supported by at
least one excellent product.
Another issue that might affect your choice of a language and a programming tool
is the level of support that they provide for the manipulation of resources. All good
Macintosh programmers make use of resources. The resource fork of an application
should contain all of the internal text, pictures, menus and windows of your program.
In this way, they are easily modified without re-compiling your code. I typically use
ResEdit to create and edit resources and this program is available through APDA.
Application Uniqueness versus “Shell” Support
When attempting to select an programming tool, it is important to evaluate how
much support you need. This decision is largely a matter of how unique your
application is in terms of the “typical” Macintosh application and the amount of time
and money you can afford to invest in “programming the interface”. Generally
speaking, the more a programming tool or shell does, the less flexibility you have in
implementing a truly unique application. I will call this characteristic the “support
-vs- uniqueness tradeoff”. Regardless of which tool you decide to purchase, it should
provide (for whatever level of support it is designed to supply) functional capabilities
as well as the expected visual properties of a good interface to your application.
A Trio of Hypothetical Applications
If you compare the vast majority of Macintosh applications, they generally
support the generation and editing of textual, pictorial or tabular data. While this is a
gross simplification it will provide some framework for the discussion that follows.
Let’s consider three programmers (with only a minor knowledge of Macintosh
programming):
Programmer A is working on a complex engineering simulation that already
exists on a mainframe. This program processes text files as input and generates text
files and graphics as output.
Programmer B is working on a new application that is, essentially, an “iconic”
programming language for educational purposes.
Programmer C is working on a text adventure game that requires a few relatively
simple dialogs but relies primarily on keyboard input in use.
The characteristics of these applications are admittedly abbreviated in order to
facilitate the discussion of the programming tools I will describe in this article.
However, I think that they are representative of the types of programs an individual is
likely to write. Mainstream software (e.g., word processors) are so complex and
well-supported in the market place that I think they are beyond the scope of this
article.
Three Programmer’s “Scope-Out” Their Work
At this point, the three programmers introduced earlier are prepared to describe
the general interface features needed by their programs.
Since programmer A’s application makes heavy use of text files, it would
probably be appropriate for the application to generate the equivalent input files
through dialogs and/or supply the program with Macintosh-style text editors for the
user’s convenience. Since the application also generates graphics, it must draw and
print these pictures and ideally support the clipboard sufficiently to move both text
and graphics to other applications for embellishment. It is desirable (from a
timeliness perspective) to use as much of the existing code as possible without
sacrificing the valuable characteristics of the Macintosh interface (namely the concept
of modeless operation). Programmer A decides to implement the program in the
following manner:
The application will have one text editor which contains the input file for the
simulation algorithm and its contents will be generated by the user’s interaction with
a dialog. To execute the simulation, the user selects a menu command and, when
complete, the application will present its results in another text editor and a graphics
window. At that point, the user can alter any parameters significant to the simulation
by selecting a dialog or editing the text in the input editor and then “re-running” the
simulation. The user can copy/paste the text and graphics associated with the
application for further use in other programs.
Programmer B’s challenge is to support a very forgiving graphical programming
environment. This application must not only display graphic information, but must
understand the significance of the position and relationships of all the iconic symbols it
supports. The application might support multiple “views” of its documents and allow
the scrolling and splitting of document windows to allow the user to look at
discontinuous portions of the same document. The program should support printing
and have some special purpose dialogs for its various features. It should support the
copying and pasting of components between documents and be able to save all of a
document’s contents to disk. Programmer B realizes that this application has many
visual similarities with an object-oriented drawing program. This programmer
decides to implement the program in the following manner:
The application will have a “tool” palette of programming symbols and a
“drawing” window. By double-clicking on an object created with one of these tools,
the user may view and change any data associated with it. Since the application’s
purpose is to teach “structured-programming” the selection/copy/paste of
component(s) or module(s) is desired.
The vast majority of Programmer C’s work will be involved with the processing
of keyboard input and generating the appropriate responses. There are a few dialogs
that allow the user to make selections among weapons or the like. Printing and
clipboard support are not really necessary but saving the state of a game is important
so the programmer must support file operations. Programmer C decides to implement
the program in the following manner:
The application will make use of a single text editor for the entry of commands or
questions and the response the adventure game computes. There are also a few menu
items that are tied to dialogs for the selection of “weapons” or actions to take at any
particular moment in the “adventure”.
Introducing the Programming Tools
In the following sections, I will introduce the three programming tools that I
have purchased and used. I must preface my discussion with the following statement:
Products of this nature are constantly being improved and enhanced, and, therefore,
you should always contact the publisher concerning the features of the latest version of
a particular package prior to making a purchasing decision. The three programming
tools that I will discuss in this article fall into two general “categories”: source code
generation and pre-compiled libraries. Prototyper™ is an application which
generates resources and source code as output. MacExpress™ and FaceIt™ are
pre-compiled libraries of “interface” code.
I will introduce these products in the order of their relative support for an
application’s interface.
Prototyper
Prototyper is an application that allows a programmer (or non-programmer) to
“construct” an interface composed of menus, windows, dialogs and alerts in a
“MacDraw™ - like” environment. The user can “link” buttons and menu items to
windows, forming the essential structure of an application.
The characteristic that sets Prototyper apart from other applications is that it
can generate not only the resources associated with the user-designed interface, but
the Pascal source code (other languages will no doubt be supported in future versions)
to implement this interface. This is the first commercial product, to my knowledge,
that provides this capability. The significance of this is that the “interface designer”
can create exactly the type of dialogs and windows that are appropriate for his or her
application.
This product could be very useful when the interface for a potential application is
being coordinated with non-programmers. It is easy to use, includes an example
project, a thorough manual, and provides a good starting point for constructing the
interface for your application.
MacExpress
MacExpress is a generic application that is best described as an application
manager. It is composed of object files, interface files and a small file of “core”
resources . It is available for several popular languages and compilers. The manual is
top notch and includes several instructive flowcharts indicating the relationship
between MacExpress’ routines/data structures and your application. There are several
excellent example programs on disk. MacExpress adheres closely to the Macintosh
user-interface guidelines, supports desk accessories, handles the main event loop of
your program, provides support for menus, handles the user’s interaction with
windows, supports the use of icons in a manner similar to the Finder, and provides
assistance in creating “ dialog” views.
MacExpress, while being procedural in implementation, presents the
programmer with a very “object-oriented” environment where “objects” such as
windows and icons are sent messages. The main event loop of your application resides
in MacExpress where “raw” events are processed and translated into messages (you
may pre-process these raw events for your own purposes). These messages are then
handled by your own routines and/or passed on to the MacExpress module for
processing. Programmers familiar with the technique of passing the address of
routines in a procedure call will feel very much at home using this package.
MacExpress is compact and extremely fast in use.
In MacExpress, objects have standard routines associated with their
functionality. These standard routines can be overridden and/or used in conjunction
with your own routines. The essential idea is that, for instance, a window is sent a
message (“the mouse went down in my content region”) and your application then
responds appropriately via a “MouseDownProcedure” or just calls the generic
procedure to handle this event.
The most attractive feature, in my opinion, of MacExpress is the sophisticated
level of simplification it affords the programmer in creating windows. Windows may
contain multiple panels all allowing resizing, splitting, scaling, scrolling, and
autoscrolling. In addition to this, all of the functionality of normal “document”
windows can be given to dialog “views” and MacExpress similarly delivers
“processed” events in the form of “messages” to these composite windows.
FaceIt is a series of stand-alone code resources that provide your application
with an excellent user-interface. FaceIt accomplishes this without linking and can be
used by programs created with several languages. The manual is technical but
complete and provides a thorough discussion of FaceIt’s capabilities and how to access
them. There are several documented example programs that demonstrate how to access
the features of the product. FaceIt is heavily resource oriented and, a file of “core”
resources acts as a starting point for the resource fork of your application, in a
manner similar to MacExpress. There is also an “interface” file that contains the
declarative header needed to access FaceIt’s data structures and a short routine to
“jump” to FaceIt’s code resources.
FaceIt is “one-step” beyond MacExpress in terms of the support it affords an
application. The price for this support is a reduced ability to generate very unique
applications. However, a program utilizing FaceIt immediately has access to many
features which are extremely difficult to implement from “scratch”. FaceIt provides
your application with text editors, a scrollable graphics window (with reduced view
window), spreadsheet-type windows, complete printing support, high-level support
for modal dialogs and alerts, support for background processing under MultiFinder™,
support for DAs and the clipboard, and various memory and resource manipulation
utilities.
In utilizing FaceIt, your program will implement a main event loop that handles
program specific “commands” while FaceIt contains its own main event loop that
directly processes “raw” events. At the beginning of your own program’s “main event
loop”, your program passes control to FaceIt, and hence the user. FaceIt intercepts