Prograph CPX - A Tutorial

OOPS! Where’d they put all the semicolons?

Prograph CPX - A Tutorial

Prograph CPX is a commercially-supported, self-contained, object-oriented programming language and development environment running on the Macintosh. It can produce small footprint, stand-alone applications, and is packaged with an application framework - called the Prograph ABCs (Application Builder Classes). The ABCs are roughly comparable in the breadth and depth of their functionality to other Macintosh frameworks like MacApp [Schmucker, 1988] and TCL [Parker, 1993]. While we’ll touch on all three aspects of Prograph - the language, the environment, and the application framework - the major emphasis will be on the framework, its structure, and its use.

“Prograph integrates four key trends emerging in computer science:

• Prograph is a visual programming language

• Prograph is object-oriented

• Prograph supports dataflow specification of program execution

• Prograph provides an object-oriented application building toolkit.”

- from the Prograph 2.5 manual, page 1

Prograph offers these unique features:

• its language: an object-oriented, visual, dataflow language,

• tight integration of the language with the editor, interpreter, and debugger into a single unified development tool

• several aspects of the ABCs, including the ability to package classes with custom graphical editors for their instances.

Prograph CPX is the principal product of Prograph International, and has been shipping on the Macintosh since 1988. It is positioned as a development tool that has the interactive ‘feel’ of the Macintosh Finder, yet with all the power to access any Macintosh internal that can be accessed from any C, C++, or Pascal programming tool. In fact, it would be reasonable to state that Prograph is the first industrial-strength visual programming system.

Prograph users run the full gamut of Macintosh application developers: from former HyperCard scripters or 4D developers, to those who are quite comfortable using MacApp or TCL in C++, and from developers who are primarily concerned with the functionality of their product (application developers) to those who are more concerned with the data content of their work (title developers). They have used Prograph to implement shrink-wrapped products, in-house applications, prototypes, and database front-ends, among other uses.

As of this writing (September 1994), the current version of Prograph is limited to producing applications - non-stand-alone code fragments like XCMDs, WDEFs, PhotoShop plug-ins, etc. can’t be implemented with Prograph, although Prograph International plans to remove this restriction. In addition, Prograph only builds 68K-based Macintosh applications, although here too, they have plans to produce PowerPC, Windows, and Unix applications.

This article will describe the Prograph language and environment, and then discuss the Prograph application framework, the ABCs, in some detail. Where appropriate, comparisons will be made with other Macintosh application frameworks, most notably MacApp.

Prograph - The Language

The Prograph language is an iconic language. The programmer codes by constructing drawings and the Prograph interpreter and compiler execute those drawings. Figure 1 shows a simple piece of Prograph code which sorts, possibly in parallel, three database indices and updates the database. To many programmers, drawing a program seems very strange at first, but the power and clarity of code expressed in Prograph is undeniable. The power of the language has to do with its primitives and the ways in which they can be used to express a computation, and explaining the language’s syntax and semantics is the purpose of this section. 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.

Figure 1. A simple piece of Prograph code which sorts -possibly in parallel - three indices and updates the database. Data flows from top to bottom, and operations - represented by icons - can execute whenever all their inputs are satisfied.

Figure 2. Some of the basic elements of the graphical design ‘language’. Classes are represented by hexagons, data elements by triangles, pieces of code by rectangles with data flow code inside, and inheritance by lines or downward pointing arrows.

The Prograph language has a graphical design and consistency which can be expressed in a small number of basic representations. Among these representations are: classes are represented by hexagons, data elements by triangles, pieces of code by rectangles with a small picture of data flow code inside, and inheritance by lines or downward pointing arrows. We see in Figure 2 some of these representations used in their simplest forms. The representations can then be combined and used in a variety of language elements. For example, initialization methods - which are associated with an individual class - are depicted as hexagonally shaped icons with a small picture of data flow code inside. Triangles represent instance variables in a class’ Data Window to show that they’re data. Hexagons drawn with edges and interiors similar to the instance variable triangles represent class variables. This associates them with the class as a whole while also associating them with data. Figure 3 shows some of these more complex representations.

Figure 3. The elements of the graphical design ‘language’ representations of Prograph can be combined in ways that are surprisingly self-consistent and easy to learn. In this figure we see three examples of this: initialization methods , instance variables, and class variables.

Object-Oriented

The Prograph language is object-oriented. In particular, it is a class-based, single inheritance (a subclass can only inherit from one parent), object-oriented language with dynamic typing and a garbage collection mechanism based on reference counting. The programmer can design and implement new classes, visually specifying the new class’ inheritance, additional instance or class variables, modified default values for inherited instance or class variables, and new or overridden methods.

Polymorphism allows each object to respond to a method call with its own method appropriate to its class. Binding of a polymorphic operation to a method in a particular class happens at run-time, and depends upon the class of the object. The syntax for this ‘message send’ is one of the more unusual aspects of Prograph’s syntax. The concept of ‘message sending’ per se is not used in Prograph. Rather, the idea of an annotation on the name of an operation is used. There are four cases:

• No annotation means that the operation is not polymorphic.

• ‘/’ denotes that the operation is polymorphic and is to be resolved by method lookup starting with the class of the object flowing into the operation on its first input.

• ‘//’ denotes that the operation is polymorphic and is to be resolved by method lookup starting with the class in which this method is defined.

• ‘//’ plus super annotation means that the operation is polymorphic and resolves by method lookup starting with the superclass of the class in which this method is defined.

In addition, Prograph is one of the few object-oriented languages in which there is no SELF construct (or a ‘this’ construct, to use the C++ terminology).

Figure 4. A typical piece of Prograph code showing comments, use of different types of operations, data flow (straight lines) and synchronization primitives (the wavy line).

Prograph has an almost completely iconic syntax, and this iconic syntax is the only representation of Prograph code. (Figure 4 shows a small code fragment typical of the Prograph language.) There is no textual equivalent of a piece of a Prograph program - the Prograph interpreter and compiler translate directly from this graphical syntax into 68K code. The icons of the Prograph language represent some twenty types of operations and Figure 5 shows most of the lexicon of the language. The inputs and outputs to an operation are specified by small circles at the top and bottom, respectively, of the icons. The number of inputs and outputs - the operation’s arity - is enforced only at run-time. In addition, there are a variety of annotations that can be applied to the inputs and outputs, or to the operation as a whole to implement looping or control flow. The visual syntax of Prograph has been formally specified. [Cox and Pietrzykowski, 1988]

Visual languages like Prograph sometimes suffer from the spaghetti code problem: there are so many lines running all over that the code for any meaningful piece of work actually ends up looking like spaghetti. Prograph deals with this issue by enabling the programmer to ‘iconify’ any portion of any piece of code at any time during the development process. This iconified code is called a ‘local’. Effectively, locals are nested pieces of code. There is no limit to the level of nesting possible with locals, and there is no execution penalty to their use. In addition, locals can be named and this naming, if done well, can provide a useful documentation for the code. Figure 6 shows the same piece of Prograph code with and without the use of locals. Note also that long names, often containing punctuation or other special characters can be used for the names of locals. The proper use of locals can dramatically improve the comprehensibility of a piece of code. The one negative aspect of their use is the so-called “rat hole” phenomena - every piece of code in its own rat hole. This can sometimes make finding code difficult.

Figure 5. Most of the iconic syntax of the language.

Figure 6a. The code to build a dialog box containing a scrolling list of the installed fonts without the use of Prograph locals to factor the code.

Figure 6b. The same code with Prograph locals to factor the code.

Three of the most interesting aspects of the Prograph syntax are list annotation, injects, and control annotation. Any elementary operation can be made to loop by list annotating any of its inputs. When this is done, the operation is invoked multiple times - one time for each element of the list that is passed on this input. Thus, list annotation on an input causes the compiler to construct a loop for the programmer. Since this annotation can be made on a local as well as a primitive operation, this looping construct is quite powerful. In addition, list annotation can be done on a output. On an output terminal, list annotation causes the system to gather together all the outputs at this terminal for every iteration of the operation and to pass as the ‘final’ output of the terminal this collection of results as an output list. List annotation, then, enables the programmer to easily make an operation into a loop that either breaks down a list into its component elements and runs that operation on the elements, or to builds up a list from the multiple executions of an operation. An individual operation can have any number of its inputs or outputs with list annotations. Figure 7 shows several examples of list annotation.

Figure 7. Examples of list annotation, an efficient mechanism for iterating over a list. The operation will automatically be called repeatedly for each element of a list, or its outputs will be packaged together into a list.

Figure 8. Simple use of inject to determine a procedure at run-time.

Inject lets you pass a name at run-time for an input which expects a function. For those familiar with Smalltalk, Prograph’s inject is similar to Smalltalk’s perform. It is also not too dissimilar from procedure variables in Pascal or function pointers in C. Suppose, for example, that you want to implement a function FooMe that takes two arguments: a list of objects, and a reference to a method to be applied to each of those objects. In Object Pascal pseudo-code, this function might look something like this:

/* 1 */
Function FooMe(theList: TList; Procedure DoThis(object: TObject));
{ Iterates through the list of objects applying the DoThis procedure 
}
 BEGIN
 theList.Each(DoThis);
 END;

The Prograph implementation of FooMe would look something like Figure 8. Note that just the name - as a string - of the method to be applied to each object is passed to FooMe. This string is turned into a method invocation by the inject.

The Prograph representation of inject - a nameless operation with one terminal descending into the operation’s icon - is a particularly well-designed graphic representation for this programming concept. When properly used, inject can result in extremely powerful and compact Prograph implementations of complex functions. However, when used improperly, it can result in code that is very difficult to read or debug, not unlike the computed GOTO of FORTRAN.

Control flow is the most unusual aspect of the Prograph language and is perhaps the most difficult aspect of the Prograph language for the inexperienced Prographer. It is a combination of annotations on operations and a case structure. A Prograph method can consist of a number of mutually exclusive cases. These cases are somewhat similar to the cases in a Pascal CASE statement or a C switch expression. The main difference is that unlike Pascal or C, the code to determine which case will be executed is inside the case, not outside it. A small example may make this clear. Suppose that we want to implement a small function that has one integer input, and if that input is between 1 and 10, the value of the function is computed one way; if it is between 11 and 100, another way, and if it is anything else, yet a third way. In Pascal-like pseudo-code, this function would look something like this:

/* 2 */
Function Foo( i: Integer): Integer;
Begin
 Case i of
 1..10: Foo := Calculation_A(i);
 11..100: Foo := Calculation_B(i);
 OtherwiseFoo := Calculation_C(i);
 End;  {Case}
End;  {Foo}

The implementation of Foo in Prograph would also involve three cases, and it would look like Figure 9. The control annotations are the small boxes on the right of the match primitives at the top of the first two cases. (Note that the window titles show the total number of cases in a method, and which case this window is, as in “2:3” the second of three cases.) In this simple example, the same annotation - a check mark in an otherwise empty rectangle - is used. The semantics of this annotation are: “If this operation succeeds, then go to the next case.” The check mark is the iconic representation of success, and the empty rectangle represents the ‘go to the next case’ notion. If the check mark were replaced by an ‘x’, then the semantics would have been: “If this operation fails, then go to the next case”. In addition to the otherwise empty rectangle, there are four other possibilities, and the five different semantics of control annotations are shown together in Figure 10. It is a run-time error and a compile-time warning to have a next-case control annotation in a location where it cannot execute, for example, in the last case of a method.

Figure 9. The Prograph equivalent of a small Pascal Case statement.

Figure 10. The different actions possible with a control annotation.

DataFlow

The Prograph language is also a data flow language. Typed data elements flow along the data wires from the outputs of one operation to the inputs of another. Execution of an operation can take place any time that data is available on all of its inputs, but otherwise the order of execution is non-deterministic. This is often a conceptual stumbling block for the new Prograph programmer, probably because of prior training in linear, textual languages with their implicit execution order. In reality, however, order of execution is often an unnecessary detail in the implementation of an algorithm and Prograph frees the programmer from having to specify this unneeded detail - once, of course, that the programmer learns to differentiate the unnecessary specification of ordering from that which is necessary. Should an algorithm require that a particular operation, named A, be executed prior to another operation, B, the programmer can enforce this by connecting a synchro from A to B and Prograph will guarantee that A is executed before, although not necessarily immediately before, B. (An example of a synchro in use can be see in Figure 4. This synchro ensures that the window’s title is set before the superclass’s Open method is invoked.) As you would probably expect, it’s not uncommon to see beginning Prograph programmers use a few unnecessary synchro connections.

Data Types and Primitives

There are ten data types in the Prograph language: boolean, integer, real, string, list, external structure, NULL, NONE, undefined, and object. Type checking is performed at run-time at the execution of each operation. A type error will cause the application to halt. If the application is being run under the interpreter when a type error occurs, then control will be transferred to the interpreter and the programmer will be given the opportunity to correct the error - either by modifying the code or by modifying the data value - and continuing execution. If the error occurs in a compiled application, the application will catch the error, quit, and return to Finder.

In addition, there are 307 primitives that are effectively part of the language. These primitives include functions in the following areas, among others: math, list processing, I/O, string processing, and interpreter control. Figure 11 presents the entire set of primitives.

New external primitives can easily be added. In fact, this is how the Mac Toolbox traps are supported: as ‘external’ primitives defined in files that are supplied with CPX. It is relatively easy to add new external primitives, and this is the means that existing libraries of C or Pascal functionality can be brought into Prograph. Once this is done from some library, these external primitives are supported at exactly the same level as Mac Toolbox traps. Thus, it is not the case that C or Pascal libraries that you bring into Prograph are somehow ‘second-class’ citizens in the Prograph language. This is the means by which new Mac system calls (e.g., QuickTime or the Drag Manager) are added to Prograph. Prograph International tries to keep up with the steady stream of additional Mac APIs coming out of Apple, but if for some reason they have not yet gotten to the nifty new API that you want to use, you can just do the work yourself to bring this functionality into Prograph as a new external primitive. There is no easy way today, however, to bring in C++ libraries, especially in a way that would retain the inheritance structure of the C++ library.

Prograph - The Environment

In this section a quick (and necessarily incomplete) overview of the Prograph programming environment will be presented. Normally the programming environment, although of great importance to the actual use of the language and framework, is tangential to a discussion of the syntax of the language and the design of the framework. For Prograph this is not true, due to the highly integrated nature of all three of these. However, to keep this chapter of manageable length and because the main subject of this book is frameworks, this subsection on the Prograph environment will be brief.

The Prograph environment consists of two tools: a compiler and a combined editor/interpreter/debugger, usually called the interpreter or the just simply ‘the environment’. (Calling this second tool the ‘interpreter’ is an historical artifact that is now technically inaccurate since the current version of the ‘interpreter’ is an incremental compiler.) Typically, an application is designed, implemented, and debugged in the environment and then as a final step, compiled by the compiler. In this section, each of the three aspects of the environment will be described separately. This separation is a convenience for the purposes of exposition.

Figure 11. A list of the Prograph primitives organized by category.

Editor/Interpreter/Debugger

The editor is a structured graphics editor that understands the syntax of the Prograph language. This editor simultaneously assists the user in entering Prograph code with a minimum of hassle and enforces Prograph syntax so that it is not possible enter syntactically incorrect Prograph expressions. The editor also enters the correct arity for any primitive, universal, or method after the programmer enters the name. (There is also a mechanism so that the name does not have to be typed in.) Figure 12 shows the sequence of editor actions for entering a simple Prograph method.

Figure 12. (above and right) The Prograph editor provides an ideal environment for entering, testing, and debugging Prograph code. This long figure documents the series of actions that a programmer would take to enter a small method. Note that because of the support of the Prograph editor, it is not possible to enter a syntactically incorrect Prograph expression. In effect, the Prograph editor is the graphical Prograph language what a syntax-directed editor can be to a textual language.

The environment includes an incremental compiler and you can run the application you’re developing under control of the environment. While doing so, you can interrupt the application, examine data values (Figure 13), change data values and code, and resume execution of the application.

Figure 13. Inspecting data values in code when execution is interrupted at a breakpoint. Execution can be resumed, or can be carried out operation by operation (analogous to line-by-line execution in debuggers of textual languages).

In effect, the environment includes a graphical interface builder, but implemented in a somewhat unusual manner. Specific editor classes - themselves written in Prograph - provide individualized graphical editors for each one of the main ABC classes. Figure 14 shows a collection of these editors. These editor classes - called the ABEs - are executed in separate lightweight processes when the programmer is graphically editing one of the ABC instances. The ABEs are present only in the environment, and are not included in a compiled application. For this reason, they are also called interpreter-only classes or sections.

Compiler

After an application has been developed and debugged, it can be compiled in what is essentially a batch process. The resulting application is a standard, double-clickable Macintosh application. In a later section, comparisons of the RAM footprint and execution speeds for compiled applications will be made.

Figure 14. A collection of Application Builder Editors -
graphical editors for many of the classes in the application framework.

Figure 15. The use of aliases to classes in different sections.
Note that the iconic representation for the alias -
a class icon with a super-imposed downward pointing arrow and an italic name -
is the nice mix of the graphical language of the Macintosh Finder and that of the Prograph language.

Other features of the Environment

There are many more aspects of the Prograph CPX environment than can be covered in this short chapter, including a help system for all the Prograph primitives and ABC classes and methods, as well as all the Mac Toolbox calls, a variety of accelerators for ‘power’ users, the manner in which comments and other documentation are supported by the environment, and the way in which the environment is actually used in practice to support an ‘outside-in’ development style.

Prograph - The Application Framework

In this section, basic statistics and run-time architecture of the Prograph ABCs are explained. Particular attention is paid to the run-time inter-connections between the objects that make up a running application, as opposed to the static inheritance structure of the class library. Since both the ABCs and the Prograph language itself are tightly integrated with the development environment, a lengthy explanation of how the programmer uses the ABCs in the Prograph environment is given. This section concludes with some measurements of RAM and disk footprints of several applications written with the ABCs and compares these to the equivalent MacApp applications.

Basic Statistics and Static Structure

The 161 classes of the Prograph ABCs are structured as 46 sections - independent units of compilation. Each can have classes as well as global functions and global data. References to the sections that comprise a complete application are stored as a project. (The project stores little else besides references to sections and Macintosh resources (icons, sounds, cursors, and other Macintosh Toolbox structures.)) Names of classes, global functions, and global data must be unique in a project. The programmer can add any number of new sections to a project.

Inheritance links can span any number of sections. The programmer’s interface for this is a particularly elegant extension of the notion of an alias from the Macintosh Finder [Apple, 1993]. While there can be only one class named ‘Foo’ in a project, there can be any number of aliases to this class in other sections. In all respects except adding new instance variables and changing the superclass, aliases act just like the original class. Thus, if there was a need to implement subclasses of ‘Foo’ in two different sections, the programmer would only have to add an alias to Foo in each section, and then implement subclasses of each alias. Figure 15 shows how this would look to the programmer. The representation of the alias follows both the graphical design of the Finder (names in italic) and that of the Prograph language (hexagons, downward pointing arrows).

The inheritance structure of the ABCs is that of a forest of a large number of short trees. There is no single “Object” class that is the superclass of all or most of the ABC classes. In fact, a large number of classes (approximately 60) inherit from no other class. Normally, this would be an unusual and perhaps sub-optimal structure for an application framework. This is not the case for the ABCs because ‘object’ is a basic data type of the Prograph language and because of the large number of language primitives (approximately 300) many of which provide much of the functionality found in the Object class in other systems. For example, cloning, both shallow and deep, is accomplished via the copy primitive rather than a Copy method in class Object. This seems to work quite well, especially since even the built-in primitives like ‘copy’ can be overridden using the data-determined reference mechanism (where the class of incoming data determines which class will handle method calls). Figure 16 shows the inheritance structure of the ABCs.

Figure 16. The inheritance structure of the class library.

There are 2327 methods in the 335 classes in the ABCs and ABEs, and all methods are provided in source code with the CPX product. Method sizes range from 0 operations (null methods) to more than 10 cases and 60 operations.

Run-time Architecture

The ABCs structure a running application in a way similar to other Mac frameworks. This isn’t too surprising since they’re all basically extensible object-oriented apps that implement the same Macintosh user interface specification. The look and feel of that specification dramatically influences the functionality of the objects that make up any framework that supports it. Thus, most of the major objects of the Prograph framework will be familiar to users of these other frameworks:

Application - The root object that governs the application’s behavior and visual appearance. It allocates and initializes most of the other objects that comprise the application’s run-time structure.

Window - Object wrapper for a Macintosh window.

View - Rendering object.

Document - Defines a relationship between a window, a data file and a print layout. This object also provides the file and disk I/O behavior for the application. The actual data controlled by a document is stored in an auxiliary Document Data object.

Task - An object wrapper for request for an action, initiated by the user, or internally. (Not unlike the MacApp command object.)

Desktop - The root object that controls all the visual aspects of the application: windows, menubar, menus, palettes, etc. It is the root of the application’s visual hierarchy.

Commander - The event and command handler for the application.

Menubar and Menu - Object wrappers for the menubar and menus.

Figure 17. Run-time interconnections

Using the Framework

To build an application with the ABCs, as with any framework, you design and implement subclasses to the ABC classes, adding new instance variables and adding and overriding methods as needed, extending the ABCs to reach your desired feature set. This often involves overriding null placeholder methods. For example, override View/Draw to let the framework get to your rendering code, and override Command/Undo so the framework can use your code to automatically handle undo processing. These null methods are sometimes called “hook” methods. [Schmucker, 1988]

Common tasks include:

• Subclass Application, override Application/Update Menus to handle any application-wide menus

• Subclass Window for each type of window desired.

• Subclass Menu for each menu that will be inserted in the menu bar. Add a method or universal to handle the menu event associated with each menu item.

• Subclass Task (or Command or Behavior) for each undoable action that the user can perform.

• Subclass Document and Document Data for each type of file that the application deals with. Override, at a minimum, Document Data/Get Data and Document/Put Data so that these files can be read and written.

(Notice that designing a custom View subclass for each rendering is not part of this list. More on this later.)

The environment relieves the programmer of the tedium of constructing the many Window and Menu subclasses that are needed for any significant application, as well as providing a great deal of flexibility in the design and implementation of hook methods.

Figure 18. The Window and Button Click Behavior Editors
for a simple window.
(Note that the widget palette - one of three - is also shown.)

The Window and Menu subclasses are typically implemented indirectly via the graphical interfaces of the ABEs. Using the Window editor, for example, the programmer can not only design the graphical layout of the window instances, but can also specify the window’s resize properties (whether its views grow or shrink as the window’s size changes, for example.), the draw behavior and the key handling for its views, and the click behavior for its buttons. This is all done in a Behavior Editor. (Figure 18 shows the Window Editor and the associated Behavior Editor for one of its buttons.) When you want to change the way a class acts, you write methods for it. On the other hand, when you want to express how a single instance should behave (such as a specific window or button), you use a behavior, a command that makes an interface element respond to an event.

Behaviors provide an elegant solution to a problem that many frameworks share: the rigidity of hook methods. Because most object-oriented languages, including Prograph, require that the interface of an overridden method be identical to that of the method it is overriding, the programmer is forced into using whatever the framework designer has specified. (Conversely, the framework designer is required to anticipate the needs of all the users of the framework when designing the interfaces to hook methods.) This can result in either an interface that does not pass all the necessary information, or to one that is overly complex for the simple or average cases. The ABCs avoid all of these problems by providing what is in essence a layer of indirection between the framework and the code that will be called. This layer of indirection is the Behavior Specifier object.

Figure 19. A Click Behavior Editor example where all the behavior for the button is obtained without writing any Prograph code.

A Behavior Specifier enables the programmer, in effect, to custom design the hook method for each object. Figure 19 specifies a click method for a button that will do the following:

• allocate an instance of the class Employee Data Window

• retrieves the current value from the editable text item named “SSN”, and the boolean value of the checkbox named “Standard?”

• retrieves the value of the global (persistent) named “Employee Database”.

• include these as arguments, together with the window that owns the button, in a call to the method View/Foo Button.

Achieving certain common tasks in the ABCs

To get a feel for the use of the ABCs, the following section sketches out the manner in which the ABCs are used to perform several common tasks in application development.

Activating a menu item

To activate a menu item you have to write some code - typically in an override of the Update Menu method present in many of the CPX classes - deciding programmatically what object controls the activation of this particular menu item, and under what circumstances it should be activated.

Menu items, for the purpose of enabling, are identified by the name of their associated menu behavior, an object that encapsulates the action that a menu item represents. Your code enables the menu behavior named “Foo” and the framework determines that this is, for example, the 4th item on the 3rd menu.

While the MacApp menu enabling is handled by a background process executing periodically, the menu enabling in CPX is done on demand when the user clicks in the menubar (or types a command key equivalent to a menu item). The Event Handler/Mouse Down method passes responsibility for handling mouse downs to the Desktop object. When the Desktop/Mouse Down method determines that the mouse down occurred in the menubar, it calls the Menubar/Mouse Down method. One of the first things this method does is update the enabling for all the menus.

Consider for example two menus named ‘App Menu’ and ‘Win Menu’. The App Menu has three items and the Win Menu has two items. Let’s consider the Win Menu first. Its two items, Win1 and Win2, are enabled by the windows Win1 and Win2. The code to do this, which is executed whenever one of these windows is the frontmost window, is shown in Figure 20. This code merely calls the inherited Update Menus method as well as executing a small local that uses the Set Item Enabled? method to enable the menu item whose behavior is named “Win1”. (In this case the behavior, the menu item, and enabling object all happen to have the same name.)

All the items in the App Menu are enabled by the application object. This menu also shows that the menu item text can be different from their associated behaviors. The behaviors are named App1, App2, and App3 and these are listed in the application object’s Update Menu code. However the menu item text strings are App1, El App2, and Lé App3. The menu item strings can be localized to different natural languages or just changed in any way you require without affecting your code.

Figure 20. The menu enabling code for two menu items controlled by a window subclass.
This is the simplest example of menu enabling.

Handling a menu event

In most cases you don’t even have to write code to handle a menu event, but need only specify a Menu Item Behavior with a graphical editor which is part of the Menu class’ ABE. This behavior can be constructed so that it calls the method or primitive of your choice, with whatever arguments are needed by that code.

Of course, whatever actions you want to take place as a result of the menu item being chosen will have to be coded, but the connection between the menu item and that code is done with a behavior.

Drawing the interior of a window

Surprisingly, you often don’t need to write any code to connect your drawing code to a particular view; you connect it with a behavior. One advantage of this approach is that you typically don’t need as many View subclasses as you would in a MacApp application. In effect, the connection between a particular view and its drawing (and also interaction behavior) is stored in its Drawing Behavior (and Click Behavior) instance variables rather than being done by subclassing View and overriding its Draw (and DoMouseClick) methods.

Measurements

Prograph, used in conjunction with the ABCs, produces small footprint, stand-alone applications. The minimal Macintosh-style “Hello, World” application - with multiple windows, the standard Apple, File, and Edit menus, and printing - has a RAM footprint of about 700K.

Figure 21 presents the results of a test to compare the RAM footprints of MacApp and Prograph CPX by re-implementing several of the MacApp sample programs in Prograph. These sample programs ranged in size from about 50 to about 3000 lines of C++. The RAM footprint of the Prograph version is generally about 300-400K larger than that of MacApp. About half of this difference is attributable to the overhead of the additional symbolic data necessary to support the inject feature of the Prograph language, and a portion of the remainder can be attributed to the Prograph garbage collector.

Figure 21. RAM footprint comparisons (in K) for the
re-implementation of three MacApp samples in Prograph CPX.

Conclusion

The Prograph application framework is comparable in its breadth and depth to other commercially supported frameworks, but when the power of the Prograph language and the speed of its development environment are taken into account, Prograph CPX stands out as a superb application development tool.

References

[Cox and Pietrzykowski, 1988] P.T. Cox and T. Pietrzykowski, “Using a Pictorial Representation to combine DataFlow and Object-orientation in a language independent programming mechanism”, Proceedings of the International Computer Science Conference, 1988, pp. 695-704

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

[Schmucker, 1988] Schmucker, Kurt, Object-Oriented Programming for the Macintosh, Hayden, 1988

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

[TGS, 1989] TGS Systems, “Prograph Syntax and Semantics”, Prograph 2.5 manuals, Appendix IV, Sept. 1989 (first printing), July 1990 (second printing)