Prototyper, MacExpress & FaceIt Compared

By Doug Poland, Niceville, FL

Three Programming Tools Compared

Introduction

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 especially 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.

Languages

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

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 events; handling “generic” events (like opening a text file into one of the text editors) and passes control to your program’s main event loop when one of your “program-specific” commands is requested.

Your program will access all of FaceIt’s high-level interface utilities through a subroutine or procedure call. There are six (long integer) arguments involved in each call to FaceIt. These six arguments are single or multiple “macro commands” with any obligatory parameters that represent some unique functionality of FaceIt. Programmers new to the Macintosh will probably require little knowledge of the Macintosh ROM with the exception of QuickDraw™ (for generating lots of neat graphics).

Your program can create and/or access information in any of the windows, and it is very easy to implement complex dialogs with FaceIt. FaceIt handles the user’s interaction with a dialog and provides very simple techniques for implementing scrollable lists, pop-up menus, and filter/activation-deactivation instructions, etc. FaceIt essentially reduces the task of implementing dialogs to that of simple string manipulation.

Back to Our Programmers

Based upon the above discussions concerning the features and capabilities of each programming tool considered, I will now suggest which programming tool (among those covered in this article) would be appropriate for each programmer.

Since programmer A is involved in the generation of a complex application that already exists on another computer, this programmer is primary concerned with the amount of time and complexity that would be involved in adding an appropriate interface to the program. The best choice for this application is FaceIt. This package automatically provides text editors, a graphics window and “spreadsheet-like” windows all of which have “display options” that are user-configurable.

Because of the amount of interactive graphical support required by programmer B’s project, FaceIt would not be a reasonable choice. The need for splitting and multiple views of the same document suggests that this programmer utilize MacExpress. This package would provide the most flexible “window environment” of any of the products discussed. Programmer B must write the code associated with updating the contents of the windows, printing, any required text-editing, file operations and clipboard support.

Although the application-specific complexity is by no means negligible for programmer C’s project, the interface is quite simple. It would probably be best for this programmer to write this program from scratch while utilizing Prototyper to initially formulate the code and resources necessary for the menus, windows, and dialogs. There are several sources for text editor algorithms and these packages, in combination with Prototyper, would probably be sufficient for programmer C’s purposes.

Relative Strengths and Weaknesses of the Programming Tools

The products that I discuss in this article are, in my opinion, ideal for certain programming projects and not so ideal for others. The lack of certain features in a particular product does not necessarily represent a weakness or short-coming but might indicate a different philosophy concerning the proper “role” or level of functionality that these products should provide. With these comments in mind, I have compiled a brief summary of my opinions of each of the programming tools.

Prototyper

While Prototyper is not an application shell, it does have many features that make it ideal for the programmer new to the implementation of Macintosh dialogs, windows, alerts and menus. It is an excellent tool for the coordination of an interface “design” with non-programmers. Prototyper could be used to form the initial structure of your application’s interface, be it large or small. Prototyper is also a very educational product with regards to the use of the toolbox in creating an interface.

MacExpress

MacExpress is a true generic application manager. It has been carefully structured to support the general concepts of an object-oriented program. It is small and very fast, and produces applications with an excellent interface. While you must write the code for printing, picture/text management, supporting the clipboard, file operations, and the integration of dialogs into your code, it is probably the most extensive shell that still provides the programmer with near complete freedom in the design of an application.

FaceIt

FaceIt is a series of stand-alone code resources that implement a full-fledged application. While the programmer is limited in terms of the level of unusual or highly unique features his or her application may have, FaceIt provides complete support of printing, the clipboard, desk accessories and a very high level of support for background processing, picture/text handling and dialog management. FaceIt is also one of the few application managers that supports Fortran and Basic.

Example Program

Since the purpose of this article is to describe programming tools and what they do for the programmer , I would be remiss if I did not include an example program.

The purpose of a programming tool is to assist the programmer in generating a good application by reducing the amount of time and the amount of code that he or she must write. As an example of what a well-designed programming tool can do to assist you in your efforts, I have included a listing and screen “snap-shot” of an example plotting application that utilizes FaceIt. This program makes use of FaceIt’s “spreadsheet” and graphics windows. The example program (in Fortran) demonstrates the integration of FaceIt into your application.

      program examp
      implicit none
      .
       ”type” declarations and initializations for program 
      .
! Include FaceIt declarations 
! include StorMF.inc

! Load frequently used (but un-liked) subroutines into memory
      load JumpMF
      load toolbx

! Inform FaceIt of application’s resource file (if separate)
      name = ‘examp.Rsrc’

! Initialize FaceIt
!     -> enable auto-opening of TEXT and PICT files from Finder
!     -> set aside 50 Kbytes of space for stack expansion (for pictures)
      call FaceIt(1,0,-1,50,0,2)

! Enter your program’s main event loop
      do
!  pass control to FaceIt (and hence the user)
         call FaceIt(0,0,0,0,0,0)
         
!  process a program specific command 
         select case(MAC)         
            case(‘About’)
!   the user chose the “About Program ” menu item
!   open the “About” alert  (resource ID 1099)
               call FaceIt(0,OpnAlt,1099,0,0,0)    

            case(‘Open’)
!   the user chose the “Open” menu item for the spreadsheet window
!   present the user with the standard file dialog
!   restricting the files displayed to those of type “TEXT”
               MAC=’TEXT’ 
               call FaceIt(0,StdOpn,0,0,0,0)
               if (name<>’Cancel’) then
!   if the user didn’t press the “Cancel” button then 
                  .
                   read disk file 
                        assign numbers to the data array
                        assign column names to STR# resource 1001 using 

                        FaceIt’s SetStr utility 
                  .
               endif
!     display the array in the spreadsheet window 
!        ->give FaceIt a pointer to the array to be displayed
!        ->display the array in the spreadsheet window
               arrayptr(1) = toolbx(PTR,dat) 
               call FaceIt(1,SetSh1,500,10,0,5)

            case(‘Plot ’)
!    the user chose the “Plot ” menu item

!    transfer the information for this dialog to FaceIt
!       ->transfer dialog item list status
               do (i=1,16)                      
                  dialog(i)=plotdialog(i)           
               repeat
!       ->use list of column names (STR# 1001) in pop menus 
               listID(1)=1001
               listID(2)=1001
!       ->transfer textual information (text and numbers) to FaceIt
!         through the “name” variable (used as an internal file)
               write(name,30) title,maxY,divY,minY,minX,divX,maxX

!   open the dialog (resource ID 2000) for manipulation by the user
               call FaceIt(0,OpnDlg,2000,0,0,0)

!   after the dialog has been dismissed, process it            
               if (dialog(1)=1) then
!    if the user pressed the “OK” button then 

!    transfer the (changed) information from FaceIt to the
!    program 
!    transfer dialog item status back to program
                  do (i=3,16)                    
                     plotdialog(i)=dialog(i)    
                  repeat
!    transfer textual information (text and numbers) back to
!    program
                  read(name,31) title,maxY,divY,minY,minX,divX,maxX
!    based upon the values of this info, prepare to plot
                  .
                   set a few variables based upon info from dialog 
                  .
!    begin recording a QuickDraw picture (the plot)
                  call FaceIt(0,NewPic,0,0,0,0)
                  .   
                   draw the plot here 
                  .      draw the axes 
                  .      plot the points 
                  .
!    end the recording of the (plot) and display it 
                  call FaceIt(0,RetCtl,0,0,0,0)      
               endif
               
            case default
         end select
      repeat
  30  format(A32,F20.6,I4,F20.6,F20.6,I4,F20.6)
  31  format(A32,F20.0,I4,F20.0,F20.0,I4,F20.0)
     end

The following screen “snap-shot” captures the example program after the user has loaded some data into the “spreadsheet” window, produced one plot and is preparing to generate another.

What might not be immediately obvious is the number of features that this very small application has as a result of utilizing FaceIt. The user has access to “spreadsheet”, text editor and graphics windows with the expected scrolling, selection and editing characteristics. The application offers complete support for printing and the clipboard in all of the windows. This application also sports a functional and intuitive plot dialog that I created with ResEdit. This dialog is displayed with a single call to FaceIt and features editable text items, pop-up menus and scroll bar controls (all of which are supported by FaceIt).

This small application is an excellent example of the value of programming tools or shells. These products have unique features specifically designed to reduce the burden of generating an application’s user-interface, permitting the programmer to concentrate on the unique characteristics of his or her program and not become overwhelmed in the task of “programming the interface”.

Additional Programming Considerations

After you have completed your application using any of these products, there are a few considerations you should take a look at concerning the use of the programs. I am referring specifically to disk space requirements and operating in a shared-application environment.

Ideally, your program should take up as little disk storage as is reasonable and operate smoothly under MultiFinder. While Prototyper and MacExpress (V1.14, new version appears to have utilities for working with MultiFinder ) do not address these issues, FaceIt has some unique features in these areas.

FaceIt is really a “stand-alone” product. There are essentially three “places” that FaceIt can be located. It can be placed in the System Folder where it will be available to any program that uses it (without linking), it can be added to your program file to create a completely stand-alone application, or it can be added to the “System”, where it is available to all programs that use it and only one copy is loaded into memory under MultiFinder. Either of these techniques can be used to reduce the disk space and memory requirements of your product (which might consist of multiple applications).

Making the Decision on a Programming Tool

Any recommendations that I make to you should be considered in light of my own programming experience. I am, for the most part, involved in large, technical programming projects. My programming time is spent in the details of implementing “engineering” concepts in code and, consequently, I do not have a great deal of time to devote to “programming the interface”. In light of this information, here are my recommendations for the use of these programming tools:

If you are receiving interface input for your application from non-programmers and require several unique interface features but not a substantial amount of application support (you are writing the code for the clipboard, printing, window updating, etc.), or you just want to know how the Mac interface in dialogs and menus is implemented, get Prototyper. Prototyper is easy to use and has several truly unique features that could make it very valuable to many programmers. Prototyper supports the following compilers: LightSpeed™ Pascal, Turbo™ Pascal, TML™ Pascal and MPW™ Pascal. Future versions of this product will probably support the C language. [$125.00, SmethersBarnes, P.O. Box 639, Portland OR, 97207, (503)-274-2800].

If your are developing a unique application in Pascal, C or Assembler and need speed, excellent window and application management, you are comfortable with writing the code for printing, file operations, clipboard and dialog support, then I would suggest you use MacExpress. This package is probably the best among those discussed in this article for creating a truly “unique” application. MacExpress supports the following compilers: MPW™ Pascal, MPW™ C, Consulair™ Mac C, TML™ Pascal, Aztec™ C, Lightspeed™ C, Lightspeed™ Pascal and various “Assemblers”. [$195.00, Alsoft™ Inc, P.O. Box 927, Spring TX, 77383, (713)-353-4090].

If you are transferring an existing technical application (even in Fortran) or creating a new one and the amount of time and/or money required to “program the interface” is a critical issue, I would suggest using the programming package FaceIt. This is a particularly good choice if you find reading Inside Macintosh difficult. Integrating FaceIt into your application requires few changes to existing code and minimizes “toolbox” calls. The price that you pay for this level of support is an inability to implement any unique or unusual interface features. This package is certainly the “quickest” way to add a Macintosh interface to a program. FaceIt supports the following compilers: ZBasic™, LightSpeed™ C, MPW™ C, Language Systems™ MPW Fortran, MacFortran™, Microsoft™ Fortran, SemperSoft™ MPW Modula-2, Lightspeed Pascal, MPW™ Pascal, TML™ Pascal and Turbo™ Pascal. [ $50.00 (single compiler), $100.00 (10 compilers), FaceWare, 1310 N. Broadway, Urbana IL, 61801, (217)-328-5842].

Closing Remarks

I hope that this short article proves to be helpful to you in your evaluation of a programming tool. As I stated earlier, this article is a brief review of only three packages that are currently available. I encourage you to “shop-around” and obtain as much information as you can. Since a programming tool may, to a large extent, determine the quality of your application’s interface, it is vital (to your application’s success!) that you use the proper tool. Good Luck!