Prograph Review
Volume Number: 10
Issue Number: 3
Column Tag: Tools of the trade
A Review of Prograph CPX 1.0 
CPX is an entirely new product when compared to Prograph 2.5 here’s
why
By Terry Kilshaw
About the author
Terry Kilshaw is a free-lance consultant, writer and programmer who also gives
Prograph training seminars. He has been designing and implementing software systems
since 1979 and spent three and a half years as Manager of Software Development with
TGS Systems from 1987 to 1990. He can be reached at (604) 762-7600
Prograph CPX 1.0
Prograph CPX is the first major release of the Prograph programming language
and development environment since Prograph 2.5 shipped in October of 1991. CPX
consists of three separate parts; the Editor/Interpreter, the Compiler and the
Application Building Classes (ABCs). Each will be discussed separately below. Readers
who are unfamiliar with Prograph should see my article entitled “A Pictorial Button
Class in Prograph”, MacTech Magazine, January 1993 and “A Review of Prograph
2.5”, MacTutor, April 1992.
This product requires a minimal hardware configuration of a 68020 based Mac
with a program partition of at least 7 megabytes. Virtual memory can be used. For
“lower end” users PI Systems promise other Prograph version(s) in the near future.
What's In A Name?
Gunakara Sun Systems Ltd., (TGS Systems), was recently renamed to the more
prosaic Prograph International Inc., (PI). CPX stands for “Cross-Platform”. With
this new product name, and a new price to match, PI is clearly signalling their
marketing focus for Prograph CPX.
The Editor/Interpreter
The Project Window
While the Prograph language itself has remained the same as in the last release,
major changes have been made to the Editor/Interpreter environment. The most
obvious is the introduction of a Project window, which allows the use of multiple
Prograph source code files.
Fig. 1 The Project Window - View by Icon
Each project section can contain classes, universal methods and persistants.
Classes can be aliased across sections so that it is easy, for example, to add a new
section, open its classes window, create an alias icon for a class in another section, and
add a subclass to that. This also leads to improved organization of Prograph code
sections and faster save times, as only those sections which have been altered need to
be saved. It will also help programmers to share code sections among their own
projects and with other programmers.
The Value Window
PI’s programmers have done an excellent job of reworking the Value window.
This is the window that is used to examine the data value on a persistant or attribute,
or on a root or terminal during execution. Instead of a scrolling list of data types it has
two popup menus, one for the data types and the other giving a list of different views
for inspecting the data. Standard views are; small and large for text display, iconic for
Macintosh graphical data types and decimal, hexadecimal and ascii for integer types.
Fig. 2 The Value Window
New editors can be added to the View popup by defining an editor for a given class.
When an instance of the class is displayed in the Value window, choosing the editor
from the View popup will invoke that editor on the instance. In this way graphical or
other types of editors can be easily be integrated into the Prograph development
environment.
View By Name
Project, method, and persistant windows now sport a View By Name option as
well as the original iconic view. Items are displayed alphabetically with a small icon in
View By Name windows. Persistant values of simple types can be edited directly in that
type of window, though double clicking on the icon still displays the data value in a
Value window - a necessity for changing the value of an instance.
Fig. 3 The Project Window - View By Name
Attribute windows also have a new look. Attributes now have small icons and the
attribute value can also be edited directly in the window without the need to open a
Value window on it.
The programmer can designate any universal method as a tool, causing its name to
appear as an item in the new Tools menu. When this item is chosen the interpreter
spins off a new thread to execute the tool. See below for a description of the
multi-threaded interpreter improvements.
The Info Window
The old Info window has been replaced with a new one, modeled somewhat on the
Think C Reference program, with which it can interact. The Info window is currently
the only place that an overview of all the classes in a project can be found.
Fig. 4 The Info Window
I found this new window a delight to use, giving immediate access to the whole
class hierarchy, to all persistants, universal methods and code sections and also to
primitives and externals. It has a Go Back button so that a path can be traced back to
any relevant piece of information. The window also minimizes to the size of an icon for
speedy access. Primitives and external C and Pascal code modules can be viewed by
category and by file and the window contents can be printed.
Debugger Improvements
When a root or terminal in a Prograph execution window is clicked on, its value
appears in a single line popup. Dragging the cursor onto the popup opens a Value
window on the data value. A simple but wonderful addition!
Other changes to the debugging environment include visible breakpoints and a
simplified set of debugging options. A method that has debug turned on has a small flag
beside its icon. The banner of a case window with any type of breakpoint in it has a
dotted background in its icon, and any operation which has a breakpoint also displays a
flag.
Fig. 5 Case Window with Breakpoint & Value popup
I would also like to see a Step Out capability such that execution would continue
from the current operation in a method until the next operation in the calling method
is reached. I'd also like to see a data value window, similar to the Think C Debugger
Data window, which would display the value on a suitably annotated terminal, without
needing to stop execution.
Auto Compaction of Methods
All methods are now kept in a compacted form, automatically, keeping the source
code smaller in memory. In 2.5 this was optional, in CPX it is transparent to the user.
Faster Multi-Threaded Interpreter
The interpreter has been completely rewritten to use the system stack. PI claims
an overall 7 times increase in speed, though in specific cases I found it to be even
faster than that. On the other hand all of this increase and more is absorbed in the
overhead of running the ABCs.
The “Interpreter” actually compiles and links code in place. All of this compiled
code is kept in memory, which partly accounts for the increased memory demands of
CPX.
Memory management has been changed. The standard Mac memory manager is
used by Mac calls but Prograph instances and simple data types use a separate heap.
Although multiple execution threads can be created in the interpreter - a
necessity for the new ABCs - this capability is not yet available in compiled code,
though it may be in a future release.
Callbacks
It is now possible to pass a reference to a Prograph method to an external
language routine, such as the Macintosh Toolbox routine TrackControl, so that the
method can be called by the routine. This is done using the callback primitive and a
highly ingenious interface scheme. The callback primitive is passed the name of a
universal method and any arbitrary piece of Prograph data that you wish passed to the
universal method when it is invoked.
Callbacks that are called at interrupt level are not supported. Obviously if the
Prograph editor is stopped in the middle of the callback method, this is not going to
work! Interrupt level callback routines can still be written in C or Pascal and
integrated into the Prograph application.
The Details
Much attention has been paid to fine details of the Prograph interface in this new
release, for example icon names are now handled in the same way as System 7. The old
annoyance of clicking on a method icon's name and accidentally creating a new method,
for example, is gone. This also means that the Cut, Copy, Paste and Clear items in the
Edit menu could be consolidated, dispensing with the duplicate menu items for text
editing and object editing. Undo of text is now operational and a set of mechanisms for
straightening datalinks, (the official name for the wires that run from roots to
terminals) is available.
Fig. 6 Case Window with Local Method Popup
Case numbers in case banners are now displayed before the method name. An
option-click in the drag area of an editable case window of a local method now displays
a popup menu of its owning method(s) and section. An executing case window displays a
popup menu of its calling methods when its drag area is option-clicked. Scroll bars of
icon windows now adjust automatically to the farthest icon in the window.
Primitives
Many new primitives have been added. Two primitives, draw-style-text and
popup-menu, which also handles hierarchical popups, are used extensively in the
ABCs. A set of Appletalk primitives providing support for Appletalk Transaction
Protocol and for the Name Binding Protocol, which was previously available
separately, is now bundled with the product. There are three new bit testing
primitives, two for callbacks, a new shallow-copy primitive and eight new primitives
for interpreter control of the multi-threaded mechanisms already described. For list
handling there is a sort and a find-sorted primitive and an insert-nth, which will
prove useful. There are six new memory primitives that make it easier to deal with
reals, points and rects when they are in buffers, that convert integers to Prograph
data types and provide support for the memory manager callback routine. A complete
set of serial port primitives is included. There are two new string primitives,
integer-to-string and string-to-integer for manipulating the four character type
identifiers that are much used in Mac programming. A welcome addition to the System
primitives allows for interpreter manipulation of the comments on sections, classes,
attributes, methods, roots and terminals. For off screen drawing there are seven new
primitives that will help more sophisticated users to create graphical programs. Based
on Apple's Graphics Device Manager, these are actually implemented as a Prograph
XDEF, rather than as Primitives. The Database Engine primitives have been renamed to
the DataFile primitives, but apart from that are essentially the same as before. (See
my Review of Prograph 2.5).
The ABCs
Previous Prograph releases presented a small set of system classes that used
compiled code integral to the main Prograph Editor/Interpreter, and a corresponding
object code library for linking the system class functionality into compiled
applications. This had the merit of speed and minimal size, but on the downside was not
customizable. In the 2.5 release the situation was eased, somewhat, by returning all
events to the Prograph code for pre-processing. But it still ran into restrictions when
flow of control entered into the primitives which did the bulk of the work, for example
when drawing a Window Item, as source code for the System Class primitives was not
available.
The Application Building Classes provide all of the capabilities of the old System
Classes and integrated application editors, and a great deal more. They are written in
Prograph and all of the source code, for both the new system classes and the classes
which support the application development process, is provided.
The Prograph ABC class system differs from the Think Class Library or the
MacApp class system, for example, in that it also contains the editors and functionality
for the development side of the process -- which tends to make it big. Split into the
Application Classes and the Application Editor Classes, the former takes up on disk 3.6
and the latter 3.8 megabytes. Altogether there are 61 top-level classes with 267
subclasses.
An in-depth examination of the ABC's capabilities would require a series of
articles so I'll attempt just a brief outline of the core functionality and some lists of
features.
The Class Editors
The programmer interacts with the class system using a set of Class Editors. The
main entry point for application development is via the Application editor, which is
invoked from the Tools menu.
Fig. 7 The Application Editor
It provides immediate access to a Menus editor, a Windows editor and a
Documents editor. The Application editor is used to create a subclass of class
Application and then define its menus, windows and documents. For each document type
a Document Data subclass is created, and the programmer maps document data
attributes to window item values using the Mapping editor; produces a set of print
layouts for reports using the Print Layout editor; and defines the various behaviors
(see below) which are invoked when the user clicks on a menu item or window item or
tabs to a field. Apart from writing the method code, assuming that the classes you need