MacApp and Prograph CPX - A Comparison

By Kurt Schmucker, Advanced Technology Group, Apple Computer, Inc.

Designing and implementing an event-driven application with a sophisticated graphical user interface is a difficult task. Fortunately, a number of years ago Larry Tesler and other researchers at Apple came up with a way of making both the design and the implementation of a Macintosh application considerably easier. What they did was to design a working skeleton application that you could easily customize. Unlike earlier skeleton apps, this new one did much more, was more easily extended, and yet required you to learn much less about its inner workings. The main reason they were able to do this was that they used an object oriented language and designed their skeleton as an interlocking set of classes in that language. The resulting skeleton became known generically as an application framework and resulted in an Apple product called “MacApp - The Expandable Macintosh Application”. [1] Other application frameworks from other companies followed: some were Macintosh application frameworks and others were for other platforms. However, MacApp, as the first and the generally most full featured, remains the standard against which all new application frameworks are measured.

When CPX first came out, I embarked on a project to compare it to MacApp by reimplementing some of the MacApp sample programs in CPX, seeing what could and couldn’t be done, measuring RAM and disk footprints, measuring the performance of the resulting apps, etc. I have gotten far enough on this project to do a fair comparison, and this article will document what I have been able to do, and the conclusions I have reached.

However, not everything in this article will be objective numerical data like RAM footprint measurements. Developers are emotional about their tools, and why shouldn’t they be? You spend a great deal of time and effort learning to use a tool, and once mastered, you rely heavily on that tool for your livelihood. I am no exception to this. While I will present the factual data that I was able to generate in doing this comparison, I will also add my own personal opinions and impressions about MacApp and CPX. In addition, since it is difficult to isolate a tool from the environment it’s used in, I will also compare the total development experience of MacApp and CPX, including programming languages, build times, auxiliary development tools like direct manipulation window layout editors, etc.

Characteristics of an Application Framework

A Macintosh application framework is a set of classes in some object-oriented language designed in such a way that:

• it is a stand-alone, double-clickable, ‘vanilla’ Macintosh application. (Because it is an app, it has a working menu bar, can open multiple windows each of which are movable, resizable, etc., works with the clipboard, prints, and exhibits all the other standard behavior that a Macintosh user expects. It is a vanilla app since all the windows are empty, the menus are blank, and it prints out blank paper.)

• it can easily be extended by subclassing and overriding. (For example, to get a new type of window that draws three-d renderings of a molecule, you subclass the Window class, and override its Draw method (or the Draw method of an auxiliary object) and include the molecule drawing code in that new method.)

• it provides a set of special null methods that enable the framework to access your code. You override these methods to do routine customization like enabling menu items, processing mouse clicks, etc. (These special methods are called ‘hook methods’. [2])

• it provides an architecture that makes adding standard Macintosh UI features like undo, cut & paste, publish & subscribe, standard file dialogs, context-sensitive cursors, etc., very easy to do.

• it provides a widget set of standard Macintosh controls (for example, radio buttons, click boxes, and scroll bars).

With this definition of an application framework, both MacApp and the CPX ABCs are application frameworks, and so are THINK’s TCL [3], Microsoft’s MFC, and MetroWerks’ PowerPlant. A more comprehensive overview of frameworks can be found in [4].

Since the whole point of an application framework is to make the task of building applications easier, the typical measure of a framework’s success is the number of ‘shipping’ applications that have been built with it. (While this seems like such a common sense approach to measuring the success of a tool that it should almost go without saying, I have not always found this to be the case. At an academic conference on User Interface Management Systems - a research approach to generating GUIs automatically that has not yet seen commercial use - one smart aleck remarked that the differences between frameworks and UIMSs is that frameworks measure their success in apps/year whereas UIMSs measure their success in dissertations/decade. The really surprising part is that this remark was intended to poke fun at the lack of real-world UIMS success after many years of research, but the UIMS researchers thought that this measure was an excellent one, and accurately gauged their contributions. There is just no insulting some people.) {OK, OK, I’ll confess. The above-mentioned smart aleck was me.}

Table 1. A quick comparison of the gross characteristics of MacApp and Prograph CPX.

Are MacApp and CPX Comparable?

Table 1 shows the results of a comparison of the gross characteristics of MacApp and CPX. This quick comparison shows that these two frameworks are roughly comparable in size and targets, although MacApp, being more mature, has a considerably larger set of shipping apps.

Detailed Comparisons

Intro to MacApp

I assume that all the readers of MacTech have some knowledge of Prograph (the language, the development environment, and the ABCs) from earlier articles (for example, [5]). However, I don’t assume any previous experience with MacApp, so let me give a short intro to MacApp, from the perspective of a Prograph CPX user. (If you want a more detailed intro to MacApp, see [2] or [6].)

MacApp is a C++ Macintosh application framework consisting of over 200 classes and 2100 methods. Since it is a framework supporting the generation of Macintosh applications, many of the classes in the framework reflect the basic Macintosh UI concepts: TApplication, TDocument, TWindow, TButton, TClipboardView, and so on, and the run-time interconnections between these objects reflect the structure of most Macintosh-style apps: the single TApplication object maintains a list of all the TDocument objects which in turn maintain lists of their TWindow objects which also maintain lists of their window widgets. In addition, there are classes that represent common abstractions like views (TView), user requests for action (TCommand), and frequently used building blocks (TList).

Any typical MacApp application will have a single subclass of TApplication, one or more subclasses of TDocument, zero or more subclasses of TWindow, and one or more subclasses of TView and TCommand respectively. These subclasses will override the hook methods - all of which have the common naming convention of starting with “Do”, as in “TDocument.DoMakeWindow” and “TView.DoMouseCommand”. In these regards, MacApp and the CPX ABCs are very similar.

MacApp has always been a Macintosh-only framework: compile on the Macintosh for the Macintosh. Last May (May 94), MacApp 3.1 shipped with support for the generation of PowerPC native applications. And MacApp 3.5, with support for OpenDoc™ container apps, is now in alpha release.

There are about 200 or so shrink-wrapped apps implemented with MacApp. Of these, Adobe PhotoShop is the best known, but others include Ray Dream’s suite of high-end rendering applications, Intelligenetics GeneWorks, Spyglass Dicer, Apps MicroTV, Exis MacDSS, Odesta GeoQuery, MacTerminal, and the Apple developer tools ViewEdit and BalloonWriter. Like other frameworks, MacApp is often used for in-house applications, so its true success is often underrated.

MacApp ships with about ten example applications, all provided in source code. These range in complexity from the smallest possible MacApp application, Nothing, to a full spreadsheet application, and a small structured graphics editor. All MacApp users read, copy, and are influenced by the source code of these samples.

There are a variety of separate development tools associated with MacApp - browsers, window layout tools, source-level debuggers, run-time inspectors, etc. Some of these are provided by Apple (MPW, ViewEdit, SourceBug, and MacBrowse, to name a few) and others, often competing tools, are offered by third parties (e.g., IcePick, Object Master, The Debugger, and CodeWarrior.) Most MacApp developers feel compelled to become proficient in many of these tools. Unfortunately, the languages and user interface conventions of the tools are not uniform.

Re-implementing the MacApp Samples

The project I decided to use to do a detailed comparison between MacApp and CPX was to re-implement some of the MacApp samples. This enabled me to test a wide variety of CPX features in a number of different contexts, yet was a project of reasonable size (especially important in an ‘on-your-own-time’ coding effort). While this project has proven to be very illuminating - both about MacApp and about CPX - it is not a flawless approach for an in-depth comparison. Flaws include:

• Size. The MacApp samples range in size from tiny toy apps to small apps. Even the largest (Calc) is only about 12,000 lines of C++. Thus, this re-implementation project really doesn’t test the ability of CPX to build full size commercial products. (Of course, re-implementing PhotoShop in Prograph just to see if it can be done is a little more than I am willing to do just for fun.)

• Feature coverage. The MacApp samples were designed to demonstrate and test the features of MacApp, and thus they may not necessarily be representative of the types of apps that CPX is designed for. (At the very least, I should attempt the reverse test: re-implementing the CPX samples in MacApp. I have not done this since once I had done a significant amount of Prograph programming, it is very difficult to work up the motivation to return to the murky depths of C++, MPW, or even text-based programming at all. So, my work may be slightly one sided, but it is better than having no data at all.)

I have re-implemented four of the MacApp samples in CPX: Nothing, DemoText, IconEdit, and DemoDialogs. I used the built MacApp samples as runnable specifications for what I would implement in Prograph, and I purposely did not look at the MacApp code to see how some feature was implemented. (I have been a MacApp programmer for years and have studied the implementations of all the MacApp samples to some degree at some time or another. However, I didn’t specifically re-examine the code while I was doing my Prograph re-implementation.)

The first two of these samples, Nothing and DemoText, were extremely easy and the re-implementation effort mainly amounted to re-arranging menu items on the standard Prograph menus to match those of the MacApp samples. Primarily, the re-implementation task for these two samples was easy because the functionality of these apps is so small, and they are direct uses of classes like TTEView (in MacApp) or EditText (in Prograph) so there is very little to do but ‘wrap’ these classes in an application. Secondarily, the re-implementation was easy since there were Prograph samples that were quite similar in functionality, and all I had to do was modify and extend them slightly to match the functionality of their MacApp counterparts.

Re-implementing IconEdit was more code, but once I had fixed a small bug in Prograph’s undo handling [7][8], it was not too difficult to get all the IconEdit functionality. One portion of the app that is tricky to implement in both versions is the handling of the editing of the icon, in particular, making sure that the user can mouse down in the fatbits view, move the cursor around while drawing, and then mouse up. Of course, choosing undo should then remove all the drawing added between the mouse down and the mouse up, not just undo the setting of the last drawn bit. Here is the C++ code from the MacApp version:

TIconDrawCommand::TrackMouse: 
#pragma segment ADoCommand

pascal TTracker* TIconDrawCommand::TrackMouse(
 TrackPhase aTrackPhase, VPoint&   /*anchorPoint*/,
 VPoint& previousPoint,
 VPoint& nextPoint, Boolean mouseDidMove)
{
 VPoint fromBit, toBit, iconBit;
 short  lineLength;
 float  deltaH, deltaV;
 float  h, v;

 if (mouseDidMove) // If mouse moved since last time 
 {
    // Convert nextPoint and previousPoint to bit locations in the icon 
 fIconEditView->PointToBit(
 fIconEditView->ViewToQDPt(nextPoint), toBit);
 fIconEditView->PointToBit(
 fIconEditView->ViewToQDPt(previousPoint), fromBit);

 if (aTrackPhase == trackPress)
 {
 fOriginalIcon = fIconBitMap->Copy();
    // Make a copy of the original.
 fTurnBitsOn =!fIconBitMap->GetBit(toBit);   
    // Turn bits on or off?
 }

// The following sets bits in the icon from the bit at previousPoint 
// to the bit at nextPoint.  It is based on a simple line-drawing algorithm.
 lineLength = (short) Max(labs(toBit.h - fromBit.h), 
 labs(toBit.v - fromBit.v));
 lineLength = (short) Max(1,lineLength);     
    // This is on two lines so that Max can be "inlined"
 
 deltaH = (toBit.h - fromBit.h) / lineLength;
 deltaV = (toBit.v - fromBit.v) / lineLength;
 h = fromBit.h + 0.5;
 v = fromBit.v + 0.5;

 for (short i = 0; i < lineLength; i++)
 {
 iconBit.h = h;
 iconBit.v = v;
 fIconBitMap->SetBit(iconBit, fTurnBitsOn);
    // Set the bit in the icon
 fIconEditView->DrawBit(iconBit, fTurnBitsOn);
    //  and draw it in the edit view.
 h = h + deltaH;
 v = v + deltaV;
 }
 }
 return this;  // Return same command object.
} // TIconDrawCommand::TrackMouse 

TIconDrawCommand::TrackConstrain: 
#pragma segment ADoCommand

pascal void TIconDrawCommand::TrackConstrain(
 TrackPhase /*aTrackPhase*/,
 const VPoint&   /*anchorPoint*/ ,
 const VPoint&   /*previousPoint*/ ,
 VPoint&nextPoint,
 Boolean/*mouseDidMove*/)
{
    // This is on several lines so that Max can be "inlined"
 VCoordinate h = Min(nextPoint.h, 
 fIconEditView->fSize.h - kBorder - 1);
 VCoordinate v = Min(nextPoint.v, 
 fIconEditView->fSize.v - kBorder - 1);
 h = Max(h, (long) kBorder);
 v = Max(v, (long) kBorder);
 nextPoint = VPoint(h, v);
} // TIconDrawCommand::TrackConstrain 

TIconDrawCommand::DoIt: 
#pragma segment ADoCommand

pascal void TIconDrawCommand::DoIt()
{
 VRect editViewExtent;

 fIconDocument->SetIcon(fIconBitMap); // Set the document’s bit map.

    // SetIcon invalidates all views of the document, including the one we just drew in. 
    // To avoid flashing, validate the edit view here so it doesn’t get redrawn.

 fIconEditView->GetExtent(editViewExtent);   
 fIconEditView->ValidateVRect(editViewExtent);
} // TIconDrawCommand::DoIt 

and Figure 1 shows the approximately equivalent Prograph code (together with some of its scaffolding, so that you can more easily see what is going on.) Perhaps it is my visual coding bias, but I find the Prograph code much easier to read and quicker to understand.

Figure 1. The implementation of fatbits drawing for the
IconEdit sample program re-implementation in Prograph.

I also took the opportunity while doing the IconEdit re-implementation to add Filters & Sieves to the Prograph application framework - something I had always wanted to do with MacApp, but was never able to work up the courage to delve that deeply into the inner working of MacApp. [9] With Prograph, and especially because of its excellent editor/interpreter/debugger environment, I was able to accomplish this, and enjoyed doing it.

DemoDialogs was a much bigger effort. The MacApp version is about 3500 lines of C++ and is basically a collection of all the window types and widgets that MacApp supports, and demonstrations of how to build your own if MacApp doesn’t provide them directly. DemoDialogs is the kind of sample program that is actually a collection of small samples: you look up a portion of the source code to see how that single feature was implemented. (Other types of sample programs include those that are good starting points for certain types of applications (e.g., DrawShapes or Skeleton), those that are just tours de force of the power of the framework (Nothing), or those that are tutorial in nature (IconEdit)). The MacApp DemoDialogs has example windows of the type that are seen in every Macintosh application (save dialog, print dialog, etc.), commonly used windows (e.g., a font picker like you would see in any word processing application), some windows that you see occasionally (windows with custom controls, windows with arrays of buttons and other widgets), and then some windows that you never see, but show off some feature of MacApp (a View inspector that shows you the internal structure of any other window in DemoDialogs). The feeling that you get after using DemoDialogs for a little while is that MacApp will probably be able to build any type of window that you want, and it may even provide direct support for that kind of window.

The final result of my DemoDialogs re-implementation effort is that I was able to implement all the functionality of DemoDialogs except for only one small, but possibly significant feature: large views. (Discussed in detail below.) Figure 2 shows all the windows of the CPX DemoDialogs. (A similar figure for the MacApp implementation would be exactly the same, so I have not included it here.) The Prograph implementation of DemoDialogs, like the MacApp original, gives you the feeling that you can create any type of window with CPX. The CPX re-implementation of DemoDialogs is perhaps a little bit slower, but comparable in perceived responsiveness to the MacApp version. The Prograph version does have a somewhat little larger RAM footprint. (See the detailed measurements on RAM and disk footprints later in this article.)

Figure 2. The windows of the CPX implementation of DemoDialogs. Note that a similar figure of the windows of the MacApp implementation would be virtually identical.

The single feature of DemoDialogs that is not easily implementable in Prograph is a 10,000 element scrolling list. Like MacApp 1.0, Prograph uses standard 16-bit QuickDraw coordinates for its views. This limits the size of views. MacApp 2.0 (and later) went to 32-bit coordinate representations for all view objects, including scrolling lists. The result was that the biggest scrolling list that I could build in Prograph was about 1,000 elements in length. Whether this is significant to you or not, depends in the types of applications you want to do. Details of the DemoDialogs re-implementation are discussed in [10].

Which is Better, MacApp or CPX?

There is no quick easy answer to the question of which of these two frameworks is better since both products are significant, feature-rich frameworks that provide great utility to their users. In addition, there are many of aspects of both MacApp and CPX that this sample re-implementation test doesn’t stress. For example, both MacApp and CPX support far code and far data - features that will only really be used in larger applications (greater than 4000 methods or more than 32K of global data). However, it is possible to list some of the aspects of each that are better than those of the other framework.

What’s Better in MacApp?

Sample Programs. The MacApp sample programs are significantly broader and deeper than those in Prograph, and there are more of them.

Clipboard View. While both MacApp and CPX support the Macintosh clipboard for copying and pasting of text and pictures, MacApp also implements a clipboard view so that you can trivially add a “Show Clipboard” menu item to your application. I also found the MacApp approach to providing clipboard support for your application’s data types (TApplication.MakeAlienViewforClipboard) to be much easier to understand and to use. (I do wish, however, that MacApp’s clipboard supported more than just text and pictures, but also included QuickTime movies, sound, etc.)

Low memory handling. MacApp’s mechanism for dealing with low memory situations is more robust and more useful than Prograph’s Rainy Day Fund.

Publish and Subscribe. MacApp provides a framework for supporting the Macintosh publish and subscribe mechanism (actually, it is a unified framework for the clipboard as well as P&S). MacApp handles a lot of the details of the P&S user interface (borders, standard dialog boxes, etc.) for you.

Adorners. MacApp’s mechanism for adding some drawing adornments to views is better at this task than the borders mechanism is in CPX. For one thing, the adorners mechanism enables you to add multiple adorners to a single view.

What’s Better in CPX?

Language. Prograph is a more readable, simpler language than C++, yet it is just as powerful. In fact, it isn’t possible to write syntactically incorrect Prograph code, and semantic errors often jump out at you in even the most casual examination. The clarity of code expressed in Prograph is due, in part, to the fact that algorithms, by their very nature, have an inherent internal structure. Often, implementing an algorithm in a textual, and thus necessarily linear fashion, hides this structure. In contrast, the Prograph language brings this structure to the surface and enables the Prograph-literate programmer to grasp this structure in a single gestalt. Prograph programmers also don’t need to spend time thinking up descriptive names for temporary variables in their code, they just draw a data flow line between the point where the data is generated and where it is used. Data is typed dynamically and this makes both prototyping and significant architectural changes easier.

Environment. Prograph has a fast garbage collector, an integrated source-level debugger - which lets you change code or data while your application is running - and an extensible window and view editor.

Behaviors. Behaviors provide a much easier to use, and much more flexible way for your code to be accessed by the framework than MacApp’s hook methods. With a behavior, you are no longer constrained to the parameter list of the hook method. In addition, CPX will retrieve some data for you (like getting values out of text items in dialog boxes.) Consider, for example, the task of responding to a click on a button in a dialog box. Here is what you have to write in MacApp:

TModelessBeepDialog::DoEvent: 
#pragma segment ARes

pascal void TModelessBeepDialog::DoEvent(
 EventNumbereventNumber,
 TEventHandler*  source,
 TEvent*event)// override 
{
 long i;
 long maxi;

 switch (eventNumber)
 {
 case mButtonHit:  // Default button and Enter or Return key
 {
 maxi = ((TNumberText *)
 (FindSubView('numb')))->GetValue();
 if (this->IsHierarchyValid())
 for (i = 1; i <= maxi; i++)
 gApplication->Beep(2);
 break;
 }
 default:
 inherited::DoEvent(eventNumber, source, event);
 }
} // TModelessBeepDialog::DoEvent 

Figure 3 shows the simple dialog you have to fill out, and the small amount of code that you have to write to achieve the same result in CPX.

Figure 3. Handling a mouse down in a button is easy because of Prograph Behaviors.

Menus. For the MacApp programmer, menus exist at the boundary between the object world of MacApp and the lower-level world of the Toolbox. Some of the programming tasks are in one world and language (DoSetupMenus) and some in another (“Arrow”, noIcon, noKey, noMark, plain, cArrow). Having taught many MacApp classes, I can testify that this can be a considerable stumbling block to the new MacApp user. Thus, in the total task of adding a new menu or menu item to a MacApp application, you have to constantly flit back and forth between a number of different programming tools each with its associated language(s) and style of usage. You code in an object language to implement the main functionality of your app, in a strange C-like language (Rez) to describe your menus, and in even stranger language (MPW Shell) to build your application. Along the way you have to use separate applications (e.g., ViewEdit and ResEdit) to build in a direct manipulation style some of the objects that your menus will operate with or on.

CPX changes this dramatically by making menus and the menubar into objects that you deal with in exactly the same way that you deal with other objects like windows and views. The Menus section in the CPX ABCs provides you with eight classes associated with menus, with the classes Menu, Menubar, and Menu Behavior among them. These classes provide you with methods that add or remove menus from the menubar, add or remove items from an individual menu, enable a menu item, test to see if a menu item is checked or enabled, and find an individual menu or menu item, among other things. You invoke direct manipulation object editors for the menubar and menu objects in exactly the same way that as for windows or views or any other object. There isn’t any need to use another separate tool to accomplish a critical portion of the basic task of implementing the menu functionality of your app. Internally, CPX still deals with the Toolbox Menu Manager and uses the Macintosh ROM to implement menus. However, all the Toolbox details are abstracted for you by CPX and you deal with menus as objects.

This small change of moving menus from the Toolbox to the framework dramatically simplifies both the programmer’s model and the task of getting that first application up and running. Just as important, abstracting away the Toolbox details simplifies porting your CPX source code to other platforms.

Offscreens. Getting smooth screen refreshes in MacApp is tricky and involves buying a third party product (OSImage) or rolling your own code in support of GWorld and offscreens. In CPX, all you have to do is allocate an Offscreen object (part of the CPX class library) and attach it to a window. Nothing could be simpler.

Simple tasks are simpler. I have found on many occasions that a number of conceptually easy tasks (opening a window, responding to a menu item choice, etc.) are just much easier in CPX than in MacApp. Here is a case in point that brings together many of these: posing a dialog. First the MacApp way:

TTestApplication::MakeModalBeepDialog: 

pascal void TTestApplication::MakeModalBeepDialog(
 CommandNumber aCommandNumber)
{
 TWindow *aWindow;
 IDType dismisser;
 long   n;

 FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));
 dismisser = aWindow->PoseModally();
 if (dismisser == 'ok  ')
 n = ((TNumberText *)
 (aWindow->FindSubView('numb')))->GetValue();
 else
 n = 0;
 aWindow->Close();
 for (long i = 1; i <= n; i++)
 gApplication->Beep(2);
} // TTestApplication::MakeModalBeepDialog 

Notice how many concepts are buried in the main line:

FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));

The view server, window templates, the MacApp failure handling mechanism must be understood, and you have to tell the C++ compiler again that the first parameter to a standard MacApp utility routine is an integer. Contrast this with the CPX way shown in figure 4. Much simpler. However, even this code is not the simplest possible. Dan Shafer suggested to me an even simpler way shown in Figure 5 in which you write no code at all. What could be easier?

Figure 4. Displaying a modal dialog in the Prograph CPX framework.
The equivalent code in MacApp is:

FailNIL(aWindow = gViewServer->NewTemplateWindow(
 (short)aCommandNumber, NULL));
dismisser = aWindow->PoseModally();

Figure 5. While the Prograph code in figure 4 looks simple,
here’s an even simpler way.

Measurements

I have been able to gather some objective data about RAM and disk footprints, and performance of one easily timed interaction.

RAM and Disk Footprints

Figures 6 and 7 show the RAM and disk footprint comparisons of four of the MacApp samples and my re-implementations of them. Note that there is a constant increment for the Prograph versions of about 200-300K in the case of disk footprints and 300-400K in the case of RAM footprints. A little more than half of this increase can be accounted for by the additional symbol tables that Prograph must maintain so that it can do by name dispatching at run-time (‘inject’ in Prograph terminology).

Figure 6. A comparison of the RAM footprints for four of the MacApp samples,
and their re-implementations in Prograph.

Figure 7. A comparison of the disk footprints for four of the MacApp samples,
and their re-implementations in Prograph.

What can’t be determined from this data is whether these increments will be remain constant as the size of the application grows, or whether they too will grow. If they are constant, then an additional 400K memory hit is not too significant when the app is expected to require a 6MB RAM partition. An examination of the RAM footprint of shipping Prograph applications shows that they do not have exorbitant RAM requirements, which suggests that the Prograph RAM increase is a constant, or a very slowly growing function.

Performance

Measuring interaction performance objectively can be difficult. Subjectively, as I already noted above, MacApp apps seem slightly snappier but approximately comparable with their Prograph counterparts.

I was able to find one interaction where objective timing data could be gathered. In the DemoDialogs application, there is a Celsius-Fahrenheit control in which the user can dial in a temperature on one scale and see the value in the other scale displayed. (See figure 8.) The dialing controls respond to mouse clicks with single increments or decrements, or if the mouse button is held down, the numbers increment as quickly as possible with all intermediate numbers displayed. This suggested to me the following test: Hold the mouse button down for five seconds in the increment Celsius control and see how large the Celsius edit text value gets in that fixed amount of time. This test measures ToolBox access (StillDown), conditional evaluation, integer arithmetic, integer to string conversion, and view refreshing. Table 2 shows the surprising results of this test. Does this mean that Prograph is ten times the speed of C++? No, it doesn’t. What this means is that language speed differences are dominated by better algorithmic choices, especially for time-consuming operations like screen refreshing, and in this particular case Prograph has the better algorithm.

Figure 8. The custom temperature conversion control, from the DemoDialogs sample, that was used for a speed test between MacApp and Prograph.

Table 2. Timing test results between MacApp and Prograph.

In this test, the mouse button is pressed for 5 seconds over the Celsius increment control, and the Celsius edit text field increase as quickly as it can, displaying all intermediate values. The table record how many degrees were incremented in the 5 seconds. The surprising result is that interpreted Prograph is about four times as fast as compiled MacApp, and compiled Prograph is about nine times as fast as compiled MacApp. Note that this does not mean that overall a Prograph app will be nine times as fast as a MacApp one, but that some computations can be.

Overall

What more can I say than that Prograph CPX is has been my development environment of choice for producing applications for the past two years or so, and will probably remain so for the foreseeable future.

References

[1] Ken Doyle, Barry Haines, Mark Lentczner, and Larry Rosenstein, “An Object Oriented Approach to Macintosh Application Development”, Journées Langages Orientés Objet, BIGRE + GLOBULE, Nov. 1984, pp. 46-54.

[2] Schmucker, Kurt. Object Oriented Programming for the Macintosh, Hayden Book Company, 1986.

[3] Parker, Richard O. Easy Object Programming for the Macintosh using AppMaker and THINK Pascal, Prentice-Hall, 1993

[4] Lewis, Ted (ed.). Application Frameworks, Prentice-Hall, 1995.

[5] Schmucker, Kurt. “Prograph CPX”, in Application Frameworks, Ted Lewis (ed.), Prentice-Hall, 1995; reprinted in MacTech Magazine, November, 1994, pp.69-80.

[6] Wilson, David A., Rosenstein, Larry S., and Shafer, Dan, Programming with MacApp, Addison-Wesley, 1990.

[7] Schmucker, Kurt. “A Tutorial on ‘Undo’ in CPX”, Visual News, July 1994, pp. 7-12.

[8] Schmucker, Kurt. “Commands and Undo in Prograph CPX”, MacTech Magazine, January 1995, pp. 18-31.

[9] Schmucker, Kurt. “Filters and Sieves in Prograph CPX”, MacTech Magazine, March 1995.

[10] Schmucker, Kurt. “DemoDialogs in Prograph CPX”, FrameWorks, Volume 8, Number 2, (March/April 1994), pp. 8-13.