Customizing AppMaker 2.0

Making AppMaker add button sounds to PowerPlant

By Andy Dent, Perth, Western Australia

A Mixed Bag of Tools

AppMaker is an interface design and code generation tool by Bowers Development. It is incredibly flexible and has a reputation for generating clear code. Many people have learned to program the Mac from studying AppMaker-generated code.

The new version of AppMaker has changed radically and you can look forward to a comprehensive review when 2.0 finally arrives. However, 2.0b4 is already an extremely usable beta. This article shows part of how a real world problem was solved with a mixture of AppMaker and PowerPlant. The main idea is to taste the essence of AppMaker - its ease of extension when you need a little bit more.

Our project was to simulate an interface with pictures, invisible buttons and sounds when the buttons were clicked. The simulation had to be compiled as a Macintosh executable for shipping to clients.

It was easy to draw up the interface in AppMaker and place the buttons, but AppMaker currently lacks support for attached sounds. Because our prototype was changing frequently, it was not feasible to repeatedly re-apply changes to the generated code. So we decided to extend AppMaker to include sounds on buttons. This required changes to AppMaker and writing some additional code:

• Change the AppMaker interface to allow us to type in the name of a ‘snd ’ resource for a button.

• Change the AppMaker definition of a window item, to store the ‘snd ’ name.

• Add logic to the code generation to allow calling the sounds.

• Add PowerPlant classes to play the sounds and attach them to the buttons.

A Brief History of AppMaker v2

Version 2 is a complete rewrite from 1.5 and looks very different. It underwent a redesign for portability, customisability, and extensibility. This included removing the need to choose your target environment up-front, making it purely a generation-time decision.

The new design was implemented with Component Workshop in 1993 and 1994. The first version (AppMaker 2.0b1) had major speed problems and was almost unusable. (Anyone remember Component Workshop, the interpretive Dylan-like environment for C++ that showed so much promise?)

In late 1994 Bowers started converting to real C++ and PowerPlant and had that running in mid 1995. The first PowerPlant version (2.0b2) was rather unstable but around 5 times faster. Versions 2.0b3 and 2.0b4 have improved since in features and stability, and Bowers Development anticipates completion in mid 1996.

Version 2.0b4 adds many crucial layout editing features such as alignment, nudging with arrow keys, etc. Support for Jim’s CDEF’s was also added; these gave very usable tabbed dialog controls. It is almost feature-complete, with very little left to do other than fine-tuning some of the interface.

Bowers Development has followed a very Metrowerks-like path of steadily increasing the features and quality of the product with their regular CD releases. OpenDoc framework generation has been available since version 2.0b3 and all the major Mac frameworks are covered as well as procedural C.

Using AppMaker - a Quick Summary

To get started with AppMaker, you either create a new document or pick up one of the samples and customize it. You can option-drag items between documents to easily copy portions across, like the standard menus. The editing environment is much like a drawing program, with a palette of window items and windoids that let you set styles and coordinates. Drag and drop is used heavily to move items around and to copy items within windows. You edit windows in a visual sense but you can also open a hierarchy much like in Metrowerk’s Constructor.

AppMaker does not let you set text fonts or styles directly, nor play with individual item colors. Instead, you define Text Styles and Drawing Styles. These are akin to the stylesheets of a word processor. This is a little strange at first, but it helps immensely when prototyping - a single style change lets you try totally different fonts or colors throughout several screens.

The basic process of use is design-generate-compile. You can also run a simulation within AppMaker to partly simulate the behavior of your screens, including buttons that open or close other windows. The code generator totally replaces the code each time, unlike v1.5 which let you choose which files to regenerate. More sophisticated regeneration behavior is on the to do list. As well as source, AppMaker generates resource files, including the PowerPlant PPob resources.

When you generate code, you first have to select a Language file. This file implies not only a programming language, but the destination framework. If you are generating straight procedural C, then a substantial number of library functions are included.

AppMaker is (largely) written in AppMaker. The AM Prefs and AM Interface files define all the data it stores, and how you edit that data. This means at any time you can add a new data field, such as to the button class, or change the interface of AppMaker. However, changes won’t affect the behavior of generated code unless you also change the language definition.

Changing the language definition is a more traditional process. A set of Templates are shipped for each language. These are text source files and very similar to C++ with a few macro commands. The templates are compiled with a separate program to create a binary language file. This compiler provides very clear feedback, making it easy to diagnose errors in your changes.

The following example is from a Quadra 700, which is no speed demon.

Build of “PowerPlant.AMMake”
(press Command-Period to cancel)
Creating PowerPlant
Compiling resource templates:
 :Resources:Main
 :Resources:Menus
 :Resources:Windows
 :Resources:Styles
Compiling source templates:
 :Sources:GenWhat
 :Sources:Main
 :Sources:Window
 :Sources:Dialog
file “:Sources:Dialog”; line 279 
// only string or int (not ‘ref’) permitted in a NameStatement
file “:Sources:Dialog”; line 279 
// Assignment, Call, or NameStatement expected
Error(s) encountered-compilation aborted
4797 lines compiled in 49 seconds
Rate = 5873 lines/min
Saving PowerPlant done

AppMaker Changes and Code Written

Changes to AppMaker

The changes can be summarized as adding a data member and an interface to set the data.

In the AM Prefs file, a Property was added to contain the name of the sound. This was simply a matter of selecting the Window Item category and choosing Edit - Add Item to add another to its list of Property Defs such as Item Kind, Command, etc. Think of this first part like changing a C++ class definition. Filling in the objects in your document is like using the classes in a C++ program.

Figure 1. The Prefs browser unwound enough to see Window Item.

When you add an item to an AppMaker definition, it is one of a number of base data types. You can refer to complex data types by creating a new category for them and using a Reference. For this version of sounds, I used just a simple String to record the sound name. A later version would rely on AppMaker being extended to contain ‘snd ’ resources. In that case, a Reference to the Sound category would be used. This is the only area of extension which requires Bowers Development to assist - they have to build in storage for the binary resource types, and functions to handle their input (via pasting) and output (in generated resource files).

Figure 2. Adding the SoundName item as a String.

After adding the data storage for sounds, I needed an interface to specify them. Note that AppMaker doesn’t force you to take this step. For any object in your document, you can always access a properties list which shows every possible property. However, I wanted the default Info dialog to display my sound name. This would let me double-click the button and see the sound with the other few crucial properties.

This interface customizing is one of the great strengths of AppMaker. When designing, you see only a few properties for each item on the screen. However, if you add something or decide that other properties should be easily accessible, it is only a few minutes work to redefine the interface to show those properties.

You edit the AM Interface similarly to editing your own projects. The only difference is, when you double-click an item in the AM Interface screen, you see a dialog letting you set its target property, such as Sound Name.

Figure 3. The Sound Demo project with the Play button double-clicked, showing the final version of the Button Info dialog with the new Sound Name field.

Changes to the AppMaker PowerPlant Templates

Only one file need be changed in the code generation to specify that a CSoundAttachment be applied to buttons that have Sound Names. In the iButton file, two procedures were changed with small additions to output extra information.

iButton changes
procedure Button.genInitMember
// add creation of attachment, if soundName specified
...
 if SoundName != “”
%
   mPlayButton->AddAttachment(
 new CSoundAttachment(“Click”, msg_Click));
%
 end if


procedure Button.getIncludeName
// add include of CSoundAttachment
...
 if SoundName != “”
 includeNames.addString (“\”CSoundAttachment.h\””)
 end if

PowerPlant classes used in the simulation

Éric Forget’s USoundPlayer was used to provide basic sound-playing capabilities from the PowerPlant Contributed Classes archives on the Internet at

<ftp://atlantis.metrowerks.com/pub/powerplant/Util/USoundPlayer.sit.hqx>.

If you haven’t visited the archives, they are well worth a look. Point your browser at www.metrowerks.com and navigate down, or go straight to

<http://www.metrowerks.com/db/powerplant/search.qry?function=form>.

CSoundAttachment was written for this project to provide an LAttachment subclass that can play sounds. It uses USoundPlayer. (Reuseable code off the Internet, what a concept!) It is shown in its entirety below, and may be useful in other circumstances.

CSoundAttachment .h
class CSoundAttachment : public LAttachment {
public:
 CSoundAttachment(const char* inSoundName,
 MessageT inMessage = msg_AnyMessage,
 Boolean inExecuteHost = true);
protected:
 virtual void  ExecuteSelf(MessageT inMessage, void *ioParam);
// data storage
 Str255 mSoundName;
};


CSoundAttachment.cp
#include  “CSoundAttachment.h”
#include“USoundPlayer.h”
#include<string.h>

// use with an entry in FinishCreateSelf, such as:
// bPlay->AddAttachment(new CSoundAttachment(“Click”, msg_Click));

//Plays sound when executed
//Suitable for use with any message

CSoundAttachment::CSoundAttachment(
 const char*inSoundName,
 MessageT inMessage,
 BooleaninExecuteHost)
 : LAttachment(inMessage, inExecuteHost)
{
 mSoundName[0] = strlen(inSoundName);
 memcpy(&mSoundName[1], inSoundName, mSoundName[0]);
}


void
CSoundAttachment::ExecuteSelf(
 MessageT /* inMessage */,
 void*  /* ioParam */)
{
 USoundPlayer::PlaySound(mSoundName);
}

Gettng Attached to your Code

Attachments are used in PowerPlant to extend the behavior of other objects, sometimes changing their behavior (such as attachments that change the background of text fields). They are an example of uncoupling objects. The LAttachment interface provides a high-level abstract interface. The object to which they are attached knows nothing of the attachments other than their presence. For example, an LButton just shouts “hoi, you mob, I was just Clicked” and carries on in ignorance. If the attachments have been created to care about Click messages, then they will react. (Attachments typically react to either all messages or one specific message, such as msg_Click.)

One subtlety is that attachments are synchronous. Thus, the button is not able to carry on with its Clicked behavior until all the attachments have been executed. Another important point to note is when the attachments are called. In the case of a Pane, it sends the Clicked message to attachments when the mouse is pressed. This means our sound is played when the user presses the button (mouse-down). Buttons inherit their attachable behavior from Panes.

If you wanted the sound to play if the user activates the button (mouse-up inside the button) then you are out of luck - there is no broadcasting to attachments when a button is triggered. An alternative to using attachments would be to add a Listener to the button. Listeners listen for results (such as buttons being released). A good exercise would be to take CSoundAttachment and rewrite it as CSoundListener.

The difference between Attachments and Listeners may seem confusing. One key point to remember is that Attachments can modify behavior - they are called before the action and return a Boolean value, so they can actually stop the action. Listeners are even more uncoupled and have no side-effect on the actions at all, being purely a way to react.

For more reading on the design ideas behind attachments, see Design Patterns by Gamma, Helm, Johnson & Vlissides ISBN 0-201-63361-2. More recent work on patterns can be found in Pattern Languages of Program Design edited by James Coplien & Doug Schmidt ISBN 0-201-60734-4. In particular, the ValueModel pattern discussed in chapter 25 seems relevant to our interface customizing and code generation work.

Is it Really so Easy?

My first exploration into customizing AppMaker was adding our OOFILE integration classes which link database fields and views to editing and display panes. This involved a number of changes to dialogs, edit text fields and other classes. A rough version, including coming to terms with the templates, took a weekend. I’ve since written the AppMaker MFC templates, so I have a fair amount of template experience under my belt.

However, small additions like the Sound Name example are relatively easy. If they are also of general benefit consider passing them on - Spec Bowers may roll them into the next release. The hard thing is deciding whether to make a tiny change now or something more generic. These Sound Name changes will probably be thrown away - it makes more sense to allow any kind of attachment to be specified and even to cope with a number of attachments.

My current project is based heavily on AppMaker and we will be experimenting further with using attachments for business rules. Hopefully this is also a good strategy for the re-generation problem. If your user-defined code is attached rather than incorporated, it won’t be trodden on when you change your project’s interface in AppMaker.

Have a good look at AppMaker - the demo’s are usually publicly available and on the CodeWarrior Reference CD’s. Hopefully this article will also have whet your appetite for using Attachments as a flexible way to program. The MacApp readers who stayed to the end may now smirk in the satisfaction of having had them for years as Adorners and Behaviors.