Related Info: Memory Manager

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.

Tools

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 are all available, the whole application, in terms of menus, windows, print layout and method call specification can be created using the supplied editors.

The programmer then writes the code for the required methods, making much use of provided methods and creating any new classes or subclasses that may be needed, inheriting or overriding superclass methods as required. After testing, it only remains to compile, document and ship. That at least, is the grand scheme which PI's architects have designed.

Behaviors

An important, though perhaps misnamed, ingredient of the ABCs is the behavior. The name behavior is misleading because a behavior does not behave. A Behavior defines, quite simply, the name of a method and a list of the inputs that are to be passed to the method when it is called.

In Prograph 2.5 a click on a button always passes the Window, the Button and the EventRecord. If what you actually needed was the value of a checkbox and the contents of the active text field, these had to be extracted from the window instance with calls to find-window-item and gets of the appropriate attributes. In CPX you use the behavior editor to pass the check box value and the Target. No programming is necessary.

Take the example of a simple OK button. In the View editor (see below) a menu item allows the specification of a click behavior for the button. In the behavior editor you will not be asked to describe what will occur when the item is clicked on, only to give the name of the method that should be called when the button is clicked and the values that should be passed to it.

Fig. 8 The Behavior Editor

Possible inputs for a Button's click behavior include: the Window it belongs to, the Button itself, the event that was generated by the click, the active Application, the current front Window, the Target, (i.e., the currently selected text item, scrolling list or whatever in the window), the Document, the Printer, the Menubar, any other Window Item, any Menu, any Window, the name of a Universal Method to be called, (with no inputs and one output, whose output value becomes the Behavior’s input value), a newly generated instance of any class, the value of a named persistant and any arbitrary constant value.

It appears that all types of Window Item can have a Click Behavior. Each Menu Item can have a Behavior. Edit and Scroll Text items have an Enter Behavior and an Exit behavior, one for when the item becomes the Target and the other for when it ceases to be the Target.

All in all, the concept of behaviors, nomenclature aside, is a powerful and significant innovation, which has the potential to simplify the programming task immensely.

The downside of this is a lot of grinding of wheels in the background and much use of injected methods which, when combined with the event dispatching mechanism, can cause perceptible delays when clicking on menus and items in windows in the interpreter, at least on a IIsi.

Mappings

A Document subclass associates a window with a file. A Document Data subclass holds the document's data when its window is not open. The Mapping editor is then used to associate the value of a Document Data attribute with a Window Item value in the window's View.

Fig. 9 The Mapping Editor

The View can be in a normal window or a print layout window. The mapping can consist of a straight value substitution or can involve a conversion of the value, for example from integer to string. Because you can write your own mapping subclasses it is possible to extend this mechanism to create whatever types of data transformation required.

Mappings then, allow the automation of another significant section of general application development, the movement of data into and out of fields and other items in a window or print layout.

Making Menus

The application's menus are defined in the Menus editor and the contents of each menu is defined using the Menu editor. The Menus editor presents a scrolling list of existing menus and shows a preview of the Menu Bar that you are creating. A command-click on the preview menu bar displays a menu's menu items. Here menus can be added, deleted and rearranged.

Fig. 10 The Menus Editor

Double clicking on a preview menu or a menu name in the scrolling list invokes the Menu Editor, where an item can be added, deleted, given a command key equivalent, associated with an icon or have its behavior specified .

Fig. 11 The Menu Editor

Users of Prograph 2.5 will note that there is no support for multiple keyboard equivalents in CPX programs, such as command-option-shift-D for example, although the Prograph editor itself continues to use them. This is a deficiency which should be remedied.

Doing Windows

Similarly the Windows editor is invoked from the Application editor, (and numerous other places within the ABCs). It shows a list of available window types. There is also a reduced representation of a Mac screen displaying the window. Different screen sizes can be chosen, such as Classic, 13", two-page and so on.

Fig. 12 The Windows Editor

All of the changes made here are made to the default instance of the window subclass to which the instance belongs. Double clicking on the window representation or on a window class name in the scrolling list launches the View editor on that window.

The View Editor

To define the contents of a window the View editor is used. Because class View is itself a subclass of Window Item, nested views are easily constructed, allowing for example, the creation of scrollable regions that may contain any type of window item.

The content area of the window is visible in the View editor. Above it are a Cancel and an OK button and to the right a floating palette with an iconic list of window item types. In fact the palette has 3 separate lists, that can be scrolled through by clicking the arrow controls at the top. To add a new item to the view you click on the item's representation in the palette, drag its outline to the place you want it within the view and release the button. The window item appears where you have “dropped” it.

Personally I found the use of this palette problematical. It gets in the way, especially on smaller screens and is very slow to redraw even on a fast machine. It is redrawn every time it is scrolled. Whenever an editor is invoked on a window item, which is frequently, the palette is laboriously hidden and, when that editor is closed, reappears and slowly redraws its contents, item by item. This has an unfortunate effect on the fluidity with which you can work in the view editor and the window item sub editors. The slower your machine, the worse it is.

Perhaps more significant is the fact that whenever you create a subclass of a Window Item class it is not automatically available in the View Editor palette. Instead it is necessary to manually add its name to a list of palette item class names in a distant area of the ABCs. If its name is too long it will wrap in the palette and be partially clipped by the next item. and there is limited space in the palette for additional item types.

Of course, because the source code is available it is possible to change the way that the ABC's work and in fact a set of Power Tools is already available from Visual Programming Inc.

The View editor gives a remarkable degree of power and control over window items and their placement and capabilities. There is a full menu of alignment options that operate on selected groups of window items; tools for manipulating the layering of items and the tab order of selectable items such as Edit Text or Scroll List items; resize properties; multiple border types; balloon help; - in short everything the designer will require for the interactive creation of sophisticated graphical user interfaces.

Fig. 13 The View Editor

Types of Window Items

Window item types are Text, Edit Text, Scroll Text, Push Button, Check Box, Radio Button, Radio Set, Scroll Bar, Scroll List, Popup Menu, Line, Rectangle, Round Rectangle, Oval, Icon, Color Icon, Small Icon, Pict, OK View, Selection View, Grid and View. For some reason CPX classifies some of these as Graphics and Resources, but all inherit from class Window Item and little seems to be gained from these extra classifications.

Most of these will be self-explanatory. PI's designers have gone to great lengths to integrate functionality into these classes. For example the Edit Text item, in addition to the obvious font, style, size, wrap and auto-scroll attributes also allows for color, transparency and a full set of border definition characteristics. In fact all window items have separately definable borders.

Graphic items, such as Rectangle, Round Rectangle, Oval, Icon, Color Icon, Small Icon and Pict can also be used as buttons, and will track the mouse and highlight appropriately

An OK View contains an OK and a Cancel button. A Selection View is one in which the user can select, drag and resize any window items within it, greatly facilitating the creation of interfaces with selectable and dragable icons. Single and marquee selection is available. Finally, the Grid type manages a set of Graphic items arranged as rows and columns.

The Compiler

The Prograph Compiler now shares the same project file as the interpreter, though the project window shows different information, such as the file type and the file size. Interpreter-only sections can be marked as such in the interpreter, and library and resource files are only visible in the compiler.

Fig. 14 The Compiler Project Window

The new memory manager described above has also been added to the compiler and various types of optimization have been added. Certain types of multi-case methods that use simple match operations on the same input terminal in each case, can now be optimized in a similar manner to C language switch statements. Under certain circumstances intermediate instance creation can be dispensed with inside a method, if the compiler determines heuristically that they are unnecessary, and the overhead for local method calls has been completely eliminated. PI is claiming an overall speedup of seven times over the same compiled code in Prograph 2.5.

Selective linking of methods has been greatly improved, with each method packaged as its own separate link unit. The linker builds a call graph using the universal method Application as its starting point. It includes all of the methods referenced by that call graph and adds any methods whose names are found in string constants, or lists of strings. This is necessary because of the extensive use of the inject terminal, where the name of a method, attribute, class or persistant is determined at run time.

Documentation

The documentation consists of four manuals: a 307 page Tutorial, a 276 page User Guide, a 208 page Extensions Reference and a 431 page ABC Reference. The general quality of the documentation is excellent and it clearly can't be faulted for lack of quantity. At the same time a great deal of information is available online, via the Info window, described above.

The only areas where it does break down are, unfortunately, in the crucial ones of introducing the ABCs, describing behaviors and the like and a long and painful chapter on the creation of Document based applications. However with two books due out on Prograph in the near future, this situation will improve. See, The Power of Prograph by Dan Shafer, (The Reader Network, 1993) and Introduction to Visual Object-Oriented Programming by Scott Steinman and Kevin Carver, as yet unpublished.

Questions, Promises and Omissions

PI is presenting CPX as a “Professional development environment, tuned for corporate and commercial application building”. While it certainly achieves this to a much greater extent than Prograph 2.5, there are still a few gaps in their professional tool set. CPX has no code profiling tools, there is no way to compare two different versions of the same source code module and code resources cannot be created using it.

At the time of writing, there is a C++ code generator in the works, developed as part of a multi-phase cross-platform strategy. In phase one the C++ code generator will be available for the Macintosh product. The code thus generated can be moved to the target platform, currently Windows or UNIX/Motif, recompiled and linked together with the ABC libraries and a third party's library of Mac-to-target functions. In phase 2 the editor/interpreter/ABCs and so on will be ported to Windows and UNIX. And in the final phase the ABCs will be reworked to provide the greatest common subset of functionality across all platforms.

PI says that they have already demonstrated functional phase 1 output at the recent COMDEX show.

Hardware Requirements

Although it is possible to run CPX in 7 megabytes of real or virtual memory on an LCII, I would not recommend it. Even on a IIsi it drags its feet and it needs a Centris 650 for response times to feel OK. Load times are another problem. To launch and load the ABC's took 2 minutes and 11 seconds on a Centris 650 in 7 megabytes of virtual memory. The IIsi is more than twice as slow. During program development crashes do happen. The turnaround time to reboot and reload CPX can be painful.

Language Overhaul?

The Prograph language itself is not quite as industrial strength as PI would have us believe. In the more than 6.8 megabytes of Prograph code, which the ABC's comprise, there is not a single case I could find of the use of instance generation operation overload nor of the overloading of get or set calls. The ABC programmers have created hundreds of methods called for example Get Font, to access the value of attribute Font, when it is only necessary to tell the programmer that there is an attribute called Font.

Prograph, unlike C++, has no provision for fast inline function definitions of the sort that make this form of data-hiding appropriate for getting and setting values in that language. These extra methods take up much space, are much slower to call than a simple get operation, (which is what most of them consist of), and require documentation.

This could of course be an attempt at data-hiding and a methodology designed with cross platform development in mind.

It is clear that from a software engineering perspective Prograph needs better data-hiding abilities; the introduction of private methods and the formalization of attribute accessing mechanisms would help, as would the introduction of datascoping rules for universal methods and persistants.

Although multiple inheritance is regarded by some as a regressive step, there are many places where it can yield elegant solutions. CPX still has only single inheritance.

Like any large class system the interlock and coupling between system elements can cause problems, when the behavior of objects needs to be overridden. In theory this should be as simple as subclassing and writing a few new methods. In practice finding your way through 7 megabytes of code, 21 levels deep in the stack can be daunting and it is particularly in this area that the documentation is weakest.

Prices, Upgrades, Royalties & Support

First the official policy. “Prograph CPX has a list price $1495 and is shipping. There is a 60-day money-back guarantee and 90 days free technical support. There are no attached royalty, delivery or deployment license fees for applications created with the basic CPX environment.”

While the list price of $1495 is a lot for the small developer or single user, it is not so for the corporate market that PI is clearly targeting. However, PI has not forgotten its faithful following. Owners of 2.5 will be able to upgrade to CPX for $299. And although PI reserves the right to change that upgrade price, they have assured the writer that they will keep an upgrade path open for registered owners of Prograph 2.5.

Program Translation

A 2.5 to CPX instance translator is shipped with CPX but translated programs that use the 2.5 System Classes will not be executable. PI is offering a System Class translator, for $49. The translation process involves a fair bit of manual labor and interposes another layer of classes between the user's application and the CPX ABC classes, so programs may grow and run slower. This should be included free, as part of the upgrade.

Conclusions

Prograph CPX is a superb successor to the already excellent Prograph 2.5. You will need a fast machine, 33 megahertz 68030 or better to use it efficiently. The ABC methodology, classes and editors represent a new and, I believe, better approach to the creation of applications with graphical user interfaces. Once you have used it, there is no going back.

Availability

Prograph International Inc., can be reached at Suite 200, 2745 Dutch Village Rd., Halifax, Nova Scotia B3L 4G7 Canada, 902/455-4446, or at their Sales and Marketing Office at 447 Battery St., Suite 300, San Francisco, CA 94111, U.S.A., 415/773-8234, 800/927-4847, Fax 415/391-3942.

Visual Programming Inc., 2025 Marconi Ave., Sacramento, CA 95821, (916) 646-4227.