TweetFollow Us on Twitter

Prograph CPX Tutorial
Volume Number:10
Issue Number:11
Column Tag:Visual Programming

Prograph CPX - A Tutorial

OOPS! Where’d they put all the semicolons?

Prograph CPX - A Tutorial

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

This article is an abridged version of a chapter in the forthcoming book “Application Frameworks,” edited by Ted Lewis and to be published later this year by Manning Publications/Prentice-Hall. Reprinted with permission.

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

Figure 17 shows the run-time interconnections between these objects, as they occur in a small database application that is shipped with CPX as a sample program.

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)

 
AAPL
$94.72
Apple Inc.
+0.78
MSFT
$44.83
Microsoft Corpora
-0.01
GOOG
$594.74
Google Inc.
+5.27

MacTech Search:
Community Search:

Software Updates via MacUpdate

Airmail 1.4 - Powerful, minimal email cl...
Airmail is a powerful, minimal mail client.It was designed to retain the same experience with a single or multiple accounts and provide a quick, modern and easy-to-use user experience. Airmail... Read more
Macs Fan Control 1.1.12 - Monitor and co...
Macs Fan Control allows you to monitor and control almost any aspect of your computer's fans, with support for controlling fan speed, temperature sensors pane, menu-bar icon, and autostart with... Read more
A Better Finder Rename 9.37 - File, phot...
A Better Finder Rename is the most complete renaming solution available on the market today. That's why, since 1996, tens of thousands of hobbyists, professionals and businesses depend on A Better... Read more
MacBook Air EFI Firmware Update 2.9 - Fo...
MacBook Air EFI Firmware Update is recommended for MacBook Air (Mid 2011) models. This update addresses an issue where systems may take longer to wake from sleep than expected and fixes a rare issue... Read more
FileZilla 3.9.0.1 - Fast and reliable FT...
FileZilla (ported from Windows) is a fast and reliable FTP client and server with lots of useful features and an intuitive interface.Version 3.9.0.1: MSW: Fix installation issue with locked DLLs... Read more
OS X Yosemite 10.10 DP4 - Developer Prev...
Note: This is a Developer Preview. You must be a registered Apple Mac Developer to download this update. OS X Yosemite is Apple's newest operating system for Mac. An elegant design that feels... Read more
FinderPop 2.5.6 - Classic Mac utility, n...
FinderPop is a Universal preference pane that extends OS X's contextual menus using a FinderPop Items folder much as the Apple Menu Items folder used to do for the Apple menu. It has other features... Read more
SpiderOak 5.1.7 - Secure cloud backup, s...
SpiderOak is a multi-platform secure online backup, storage, access, and sharing solution engineered for the consumer and small businesses. You must first sign up to use SpiderOak. Running natively... Read more
Espionage 3.6 - Simple, state of the art...
Espionage offers state-of-the-art encryption and plausible deniability for your confidential data. Sometimes, encrypting your data isn't enough to protect it. That's why Espionage 3 goes beyond data... Read more
calibre 1.45.0 - Complete e-library mana...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital... Read more

Latest Forum Discussions

See All

Celebrate Summer With a Cat in the Hat L...
Celebrate Summer With a Cat in the Hat Learning Library Sale Posted by Ellis Spice on July 22nd, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
MyTaskList Review
MyTaskList Review By Jennifer Allen on July 22nd, 2014 Our Rating: :: EFFECTIVE IF PLAINUniversal App - Designed for iPhone and iPad It’s not the most stylish of task management apps, but MyTaskList has all the features you could... | Read more »
FlyCraft Herbie: Crazy Machines Review
FlyCraft Herbie: Crazy Machines Review By Jennifer Allen on July 22nd, 2014 Our Rating: :: TRICKY FLYINGUniversal App - Designed for iPhone and iPad A tough game of careful thrusting and navigation, FlyCraft Herbie: Crazy Machines... | Read more »
MTN Review
MTN Review By Jessica Fisher on July 22nd, 2014 Our Rating: :: ADORABLE, SERENE, AND AMUSINGUniversal App - Designed for iPhone and iPad MTN is an adorable, talking pet mountain that is less game and more zen garden.   | Read more »
Fly High with Ninja UP! Now Available o...
Fly High with Ninja UP! Now Available on the App Store Posted by Jessica Fisher on July 22nd, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Bio Inc. Review
Bio Inc. Review By Nadia Oxford on July 22nd, 2014 Our Rating: :: SICKENING - IN A COMPELLING WAYUniversal App - Designed for iPhone and iPad Bio Inc is about orchestrating the medical destruction of a single person. If that doesn’... | Read more »
HELMUT Review
HELMUT Review By Andrew Fisher on July 21st, 2014 Our Rating: :: TRUNDLE SIMULATOR 2014Universal App - Designed for iPhone and iPad HELMUT is a fun, fleeting time-sink that offers a momentary distraction and nothing else.   | Read more »
Walkr Review
Walkr Review By Jennifer Allen on July 21st, 2014 Our Rating: :: ORIGINAL WALKINGiPhone App - Designed for the iPhone, compatible with the iPad Walking is a bit more exciting thanks to this planet building/discovering sim reliant... | Read more »
Zombie Commando Review
Zombie Commando Review By Jennifer Allen on July 21st, 2014 Our Rating: :: MINDLESS SLAUGHTERUniversal App - Designed for iPhone and iPad Briefly fun but ultimately forgettable, Zombie Commando will scratch an itch then be... | Read more »
Swords & Poker Adventures Review
Swords & Poker Adventures Review By Jennifer Allen on July 21st, 2014 Our Rating: :: SOULLESS POKER PLAYUniversal App - Designed for iPhone and iPad Swords & Poker Adventures is a mishmash of Poker and RPGing, but it lacks... | Read more »

Price Scanner via MacPrices.net

15-inch 2.0GHz MacBook Pro Retina on sale for...
B&H Photo has the 15″ 2.0GHz Retina MacBook Pro on sale for $1829 including free shipping plus NY sales tax only. Their price is $170 off MSRP. B&H will also include free copies of Parallels... Read more
Apple restocks refurbished Mac minis for up t...
The Apple Store has restocked Apple Certified Refurbished Mac minis for up to $150 off the cost of new models. Apple’s one-year warranty is included with each mini, and shipping is free: - 2.5GHz Mac... Read more
Twelve South HiRise For MacBook – Height-Adju...
If you use your MacBook as a workhorse desktop substitute, as many of us do, a laptop stand combined with an external keyboard and pointing device are pretty much obligatory if you want to avoid... Read more
Why The Mac Was Not Included In The Apple/IBM...
TUAW’s Yoni Heisler cites Fredrick Paul of Network World whoi blogged last week that the Mac’s conspicuous absence from Apple and IBM’s landmark partnership agreement represents a huge squandered... Read more
Save $100 on 13-inch Retina MacBook Pros, plu...
Adorama has 13″ Retina MacBook Pros on sale for $100 off MSRP. Shipping is free, and Adorama charges sales tax in NY & NJ only: - 13″ 2.4GHz/128GB MacBook Pro with Retina Display: $1199 - 13″ 2.... Read more
Blurr it 2.3 for iOS – Quickly Blurs Selected...
Hyderabad, India based TouchLabs has announced a new update of Blurr it 2.3, their photography app for iOS users. Blurr it allows you to blur part of the image to hide potentially sensitive or... Read more
MacBook Airs on sale for $100 off MSRP, start...
Best Buy has the new 2014 MacBook Airs on sale for up to $100 off MSRP on their online store. Choose free home shipping or free local store pickup (if available). Prices valid for online orders only... Read more
Amazon Announces Kindle Unlimited: Unlimited...
Amazon.com has introduced Kindle Unlimited — a new subscription service which allows customers to freely read as much as they want from over 600,000 Kindle books, and listen as much as they want to... Read more
New Linksys Wireless Range Extenders Boost Wi...
Linksys has announced its new lineup of Linksys Wi-Fi Range Extenders. Consumers often experience a weak wireless signal in some parts of their house or apartment caused by blocking elements such as... Read more
MacBook Airs available starting at $719
The Apple Store has Apple Certified Refurbished 2013 & 2012 MacBook Airs in stock today starting at $719. An Apple one-year warranty is included with each MacBook, and shipping is free: 2013... Read more

Jobs Board

Sr Software Lead Engineer, *Apple* Online S...
Sr Software Lead Engineer, Apple Online Store Publishing Systems Keywords: Company: Apple Job Code: E3PCAK8MgYYkw Location (City or ZIP): Santa Clara Status: Full Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Sr *Apple* Engineer - IT - Requisition #: -...
For more information about TIAA-CREF, visit our website . The Apple Engineer will provide engineering and third-level incident support for 300- 500 MacOS desktop/laptop Read more
*Apple* Systems Administrator - DISH (United...
…satellite service provider, and Dish is currently looking for an experienced Apple /Mac Systems Administrator. Apple systems administrator will be responsible for Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.