Guide Extrn Code Modules
Volume Number: 11
Issue Number: 7
Column Tag: Essential Apple Technology
Apple Guide with External Code Modules 
A real world example with design lessons
By Jesse Feiler, Philmont Softwre Mill
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
The Story So Far
Apple Guide is a major new technology available for the first time in System 7.5. In
the March 1995 MacTech Magazine article, “Apple Guide Isn’t Help”, a very brief
overview of Apple Guide touched on how it provides active assistance to users.
In this article, you’ll see a concrete example involving an AppleScript-based
coach mark and a custom-written external code module to guide a user through a task.
This case study is simple - but so are many of the activities which Apple Guide assists
users in performing. The external context check, likewise, is very basic - but so are
many of the external context checks that you may write.
The Problem To Be Solved
Imagine an environment in which a number of different people use a single computer.
Most of the time, these people will be doing simple word processing. This computer of
many masters might be in an office that employs a number of part-time and/or
temporary staff, or it might be in a shared computer room at a school, or it might be
located at a non-profit organization where volunteers drop in periodically to help in a
Good Cause.
If you are managing such an environment, it will save wear and tear on everyone
if you can tell your staff/students/volunteers that word processing can be done by
selecting the Word Processing item from the Apple menu. You create uniformity by
making an alias to WordPerfect 3.1.0 (your current word processor of choice) and
placing it in the Apple menu. This helps keep things under control, even as the busy
little bees rename the hard disk, open/close all needed/unneeded windows, etc. (Of
course, you could use At Ease or a similar product, but there are cases where such a
solution is not appropriate - most often when you need to let people have more Finder
access than At Ease allows.)
This idea is received so well that you are promoted immediately.
(Congratulations!) Now someone else has your old job and needs to know how to create
and maintain the Word Processing alias in the Apple menu. Furthermore, this strategy
is replicated throughout your organization, and it turns out that 432 office managers
now are saddled with the task of creating and maintaining this alias. Having read a bit
about Apple Guide (possibly even buying one of the excellent books on the subject), you
decide that this is a great Apple Guide project.
Where to start?
Who is the user?
Remember that Apple Guide is a very personal service that is provided to a user
who needs assistance in carrying out a task. Before flinging yourself into writing a
guide file, think about who will be using the guide file and in what context. In this
case, it’s very clear. The users will be office managers. You know from experience
that they are basically familiar with the Macintosh - enough so that they can supervise
people who know little more than how to type and select items from a menu.
Some of them - like you - are fairly sophisticated about the interface and about
what you can do with it. Others of them are rather leery of trying anything new -
particularly something that might cause a problem.
The purpose of this particularization of your users is to help you in knowing the
vocabulary to use and the degree of detail that you need to go into in your guide file.
The users in this case, for example, can be expected to be able to understand the phrase
“drag this file to the trash.” The people who are actually doing the word processing,
who may be much less sophisticated than the supervisors, may need to be told how to
drag a file and where the trash is.
Sometimes one key element will stand out and put everything else in perspective.
In this case, you decide that the best impression you can get of your typical user is that
you will need to remind the user of what an alias is. The office managers will have
heard about aliases, probably have used them, and may well have created them. But
they don’t create them every day. This simple idea gives you guidance as to the tone and
complexity of your guide file.
Whenever you create Apple Guide assistance, don’t skip this all-important step
(and don’t spend too much time on it - five minutes is quite enough in most cases). It
is very hard to provide a good service to a user if you don’t know who your user is.
What precisely do you have to do to provide assistance to the user?
In this case it seems clear: create an alias for WordPerfect. You could probably
write a little AppleScript to do it. But consider:
• what if there are multiple versions of WordPerfect on this computer?
• what if there are multiple copies of a single version WordPerfect on this
computer?
• what if WordPerfect isn’t even on this computer?
• what if WordPerfect can’t run on this computer?
The strategy that you adopt is to ask the user to run WordPerfect. In the context
of your user definition, this is a reasonable request. This pushes the responsibility of
choosing among multiple copies onto the user. If the user can’t find WordPerfect, the
Find File command is available to help in locating it. In the scope of your guide file,
you can refer the user to Macintosh Guide for more detailed assistance if necessary.
Furthmore, since installing software is part of the office manager’s job description,
you have no qualms about asking the user to do that if necessary.
What you will do in your guide file is verify that WordPerfect can run and that
the right version is running. If you only wanted to verify that WordPerfect can indeed
run, you could prompt the user to launch it and use one of the Process external code
modules in Apple Guide Standard Resources to check that WordPerfect is running. But
checking the version
Defining an External Code Module
No, there’s not doubt about it: checking the version of an application that’s running is
going to require a new external code module which will need to check that the correct
version of WordPerfect is running. As always when you write an external code module
(or in fact any code), take a moment and stop to think if you can make the code more
general without increasing development time.
In this case, you will have to check the version of WordPerfect. The version
consists of three numbers (3.1.0 for example) which are stored in two bytes in the
'vers' resource of the application (the second two are packed into one byte). Do you
need to check for version 3.x? Version 3.1.x? Version 3.1.0? Here’s an opportunity to
generalize your external code module. After no more thought than this, you decide that
the external code module will take five parameters (listed out of order):
2. The signature of the application to check.
3. The major version number to check (3 in the example above).
4. The minor version number to check (1 in the example above)
5. The bug fix version number to check (0 in the example above)
And of course, you’ll want to provide yourself (and other Apple Guide authors)
the flexibility to use this module for various checks, so the first parameter will be:
1. Which comparison to perform.
This parameter will take any of the following values:
0= Compare signature only
1= Compare signature and major version number only
2= Compare signature, major and minor version
3= Compare signature, major, minor and bug fix version.
Defining the context check in Guide Script
If you name the external code module 'apVr', your context check will look like
this in Guide Script:
SHORT, OSTYPE, SHORT, SHORT, SHORT
The context check is addressed to the Finder ('MACS'), and the parameters follow
as defined above.
You can use it in a line of code like this:
This will return TRUE if the application with signature 'WPC2' is running and if
its version is exactly 3.1.0
Likewise, this line will return true if the application with signature is running
- regardless of its version (remember the first parameter specifies the type of
comparison):
The only other thing you need to do on the Apple Guide side is to remember to
include the external code module in your guide file. If you have compiled it into a file
called “contextCheck”, just add its resource in with the following line:
And that’s it!
Preparing the context check interface
Writing the context check itself is equally straightforward, even if it involves a
few more steps. The first step is to prepare the context check to match the definitions
in your guide file. This means making certain that you compile it with the same name
('apVr') and that you are prepared to take the same parameters in the same order that
you specify them in your guide file.
If you are using MPW and your source file is named “contextCheck.c”, this code
will compile and link it:
contextCheck contextCheck.c.o
Link -sn contextCheck=apVr -mf -t extm -c reno -rt ∂
extm=1200 -m MAIN -sg myModule ∂
contextCheck.c.o ∂
"{Libraries}"Interface.o ∂
-o contextCheck
contextCheck.c.o. contextCheck.c
C -r -b contextCheck.c
In CodeWarrior, make certain that the project preferences specify a Code
Resource, creator 'reno', type 'extm', restype 'extm', resource ID 1200 (or whatever
number you’ve chosen), and resource name apVr (or whatever name you’ve chosen).
In order to make certain that the parameters arrive in your code module in the
same way that you specify them in the guide file, the easiest method is to declare a
struct:
typedef struct{
// 0 = signature only
// 1 = signature and major rev
// 2 = signature, major and minor rev
// 3 = signature, major, minor, and bug rev
short whichCompare;
OSType signature;
//note that we bring in 3 values; the 'vers'
//resource combines minorRev and bugRev
short majorRev;
short minorRev;
short bugRev;
}contextCheckData,*contextCheckDataPtr,**contextCheckDataHandle;
Now all you have to do is write the context check.
Writing the Context Check
The context check described here is brief enough and typical enough that it is included
in its entirety. It is broken up into four sections only for clarity. Paste listings 1, 2,
3 and 4 together and you’ll have the whole ball of wax.
Listing 1: Headers and housekeeping
Headers and housekeeping
What would a source code file be without these things? You might want to put these in a header (.h) file
and include that file.
#include "Types.h
#include "AppleEvents.h
#include "Errors.h
#include "ToolUtils.h
typedef struct{
// 0 = signature only
// 1 = signature and major rev
// 2 = signature, major and minor rev
// 3 = signature, major, minor, and bug rev
short whichCompare;
OSType signature;
//note that we bring in 3 values; the 'vers'
//resource combines minorRev and bugRev
short majorRev;
short minorRev;
short bugRev;
}contextCheckData,*contextCheckDataPtr,**contextCheckDataHandle;
//these are the values for whichCompare above
enum {
compareSignatureOnly = 0,
compareMajorRevOnly = 1,
compareMajorAndMinorRev = 2,
compareAllRevs = 3
};
/* prototypes */
Boolean VersionAppRunning(
short whichCompare,
OSType signature,
UInt8 majorRev,
UInt8 minorRev,
UInt8 bugRev);
OSErr SetContextResult(
void* theData,
Size theSize,
Ptr* outMessage,
Size* outSize);
(In case you’re wondering about the includes, AppleEvents.h contains the
definition of errAECorruptData, the default return value.)
As in most context checks, there are two important functions. The first
(VersionAppRunning above) does the work. The second (SetContextResult above) packs
the result into the structure that Apple Guide wants to get back. This particular
function is used almost verbatim in most context checks.
Listing 2: main
main
This is the heart of your context check. Unpack the parameters passed in from Apple Guide, call the
routine to perform the context check (VersionAppRunning) and package the result for return to Apple
Guide. All context checks have this general structure.
pascal OSErr main(
contextCheckData* msg,
Size inSize,
void* outMessage,
Size* outSize,
Handle ignoreMe )
{
// the default return value of the operation
OSErr err = errAECorruptData;
// the default return value of the context check
Boolean result = FALSE;
// this is what changes for different context checks
result = VersionAppRunning (
msg->whichCompare,
msg->signature,
msg->majorRev,
msg->minorRev,
msg->bugRev);
// this is usually the same for all context checks
err = SetContextResult(
&result,
sizeof(Boolean),
outMessage,
outSize);
return(err);
}
All of the parameters that you provide in the command are
packed into a pointer (msg above) of size inSize and are passed to your code module.
The struct that you declared above - matching the order and types of the parameters in
your command - keeps this under control.
Apple Guide wants the result of the context check returned in the pointer
outMessage of size outSize. This is a Boolean value of TRUE or FALSE, indicating
whether or not the context check is true.
In addition to the result of the context check, the module itself returns a result of
type OSErr, indicating whether or not it was able to perform the context check. At the
moment, Apple Guide only recognizes noErr for such a return value. You may want to
be more particular in reporting why you couldn’t do a context check, but Apple Guide
isn’t interested in excuses.
Listing 3: Setting the result
SetContextResult
Apple Guide wants the result passed in a pointer with its size provided in a second parameter. This is
the code that is used in most of the Mac OS context checks as well as in many others. It’s more
general than needed, but that never hurt anyone.
OSErr SetContextResult(
void* theData,
Size theSize,
Ptr* outMessage,
Size* outSize)
{
Ptr p;
if (p = NewPtr(theSize))
{
BlockMove(theData, p, theSize);
*outSize = theSize;
*outMessage = p;
return(noErr);
}
else
return(MemError());
}
Notice that if the pointer for the result cannot be allocated, this function returns
the result of the MemError function, which in turn is returned as the result of main.
As noted above, Apple Guide only looks to see if the result of main is noErr.
Listing 4: The heart of the context check
VersionAppRunning
Loop through each process on the computer until we find one that matches the signature requested.
Once we find it, check the version in accordance with the whichCompare parameter.
Boolean VersionAppRunning (
short whichCompare,
OSType signature,
UInt8 majorRev,
UInt8 minorRev,
UInt8 bugRev)
{
Boolean result = FALSE;
ProcessSerialNumber PSN;
ProcessInfoRec info;
OSErr err;
Str31 aProcessName;
FSSpec aProcessAppSpec;
PSN.highLongOfPSN = 0;
PSN.lowLongOfPSN = kNoProcess;
info.processInfoLength = sizeof(ProcessInfoRec);
info.processName = aProcessName;
info.processAppSpec = &aProcessAppSpec;
while (GetNextProcess(&PSN) == noErr)
{
if(GetProcessInformation(&PSN, &info) == noErr)
{
if(info.processSignature == signature)
{
switch (whichCompare)
{
case compareSignatureOnly:
result = TRUE;
break;
// need to check the application file’s version
default:
{
short appResource = FSpOpenResFile (
&aProcessAppSpec, fsRdPerm);
short myResError = ResError();
if (myResError == noErr)
{
NumVersion theVersion;
VersRecHndl aVersRecHndl =
(VersRecHndl)GetResource ('vers', 1);
if (aVersRecHndl)
{
MoveHHi ((Handle)aVersRecHndl);
HLock ((Handle)aVersRecHndl);
theVersion =
((**aVersRecHndl).numericVersion);
HUnlock ((Handle)aVersRecHndl);
};
CloseResFile (appResource);
switch (whichCompare)
{
case compareMajorRevOnly:
{
result = (majorRev == theVersion.majorRev);
break;
};
case compareMajorAndMinorRev:
{
result = (majorRev == theVersion.majorRev)
&&
(minorRev ==
theVersion.minorAndBugRev >> 4);
break;
};
case compareAllRevs:
{
UInt8 versionComparer = 0;
versionComparer = (minorRev << 4) + bugRev;
result = (majorRev == theVersion.majorRev)
&&
(versionComparer ==
theVersion.minorAndBugRev);
break;
};
};
};
break; // out of default case
};
};//switch statement
break; //to escape the while loop
}; //if we found the app
}; // if we got the process info
}; //while
return result;
}
Although external code modules are very simple to write, they often require a bit
of research into parts of the Mac OS you may not have wandered into before. The
Process Manager, for example, is something that many programmers never have to
deal with directly. When you start to think about writing a context check, spend a
little time with the documentation on E.T.O. (or comparable resource) - particularly
including code snippets and Tech Notes. Often, you’ll find exactly what you’re looking
for.
In this case, a while loop calls GetNextProcess and GetProcessInformation to
check each process on the computer. (This is copied directly from an example in
Inside Macintosh.) All that matters here are two values returned in the ProcessInfoRec
(“info”): processSignature, and aProcessAppSpec which is the FSSpec of the
application itself.
If a process signature (info.processSignature) matches the signature you’re
looking for, you use the whichCompare value to refine your testing. A switch
statement makes the code easier to read here. If whichCompare is
compareSignatureOnly, you set the result to TRUE. In any other case, you’re going to
have to check the actual version of the file.
Using the FSSpec returned in aProcessAppSpec, you open the resource fork of the
application and retrieve 'vers' resource 1. You take the numeric version of the
resource out, ignoring the other parts (the copyright string, etc.). Close the file and
then compare the resource with the values passed into this function.
An important point to note is that you must open the resource fork with
fsRdPerm access only. Also, in the bad old days before Preferences files, some
applications wrote to their resource forks while they were running. (Some still do.)
If you are working with such an application, untoward results may occur.
The variable result, initially set to FALSE, is set to TRUE if the appropriate test
passes. As its final statement, the function returns the value of result.
Writing other external code modules
The structure of most external code modules used for context checking is
generally the same as this one. Only the guts of the module (Listing 4) really changes
from one context check to another. Minor adjustments to the headers (Listing 1) and
main (Listing 2) are required, but they usually involve nothing more than changing
method names for readability.
An AppleScript Coach Mark
In the case study here, you can see how you can ask the office manager to run
WordPerfect and to check that the correct version is running. Now all that’s needed is
to assist the user in creating an alias for WordPerfect and installing it in the Apple
menu. That’s very straight-forward: just draw a coach mark around the WordPerfect
application, and coach the user through the process of creating an alias.
Well, conceptually it’s very straight-forward. If you have asked your user to
run WordPerfect, who knows if the WordPerfect icon is now visible on the desktop?
Did the user launch WordPerfect by clicking on a WordPerfect document? By using an
alias in the Recent Applications folder of the Apple menu? No, somehow or other you’re
going to have to make certain that the WordPerfect application icon is visible and you
have to be able to coach it.
You can define an AppleScript coach mark with a command like:
REDCIRCLE, "wp icon script
If you write an AppleScript that will provide the coordinates of the WordPerfect
icon (and make certain that it’s visible!) and save that compiled script in a file called
“wp icon script” this line of code will work - provided that the script is co-resident
with your Guide Maker source files at compilation time.
Like the external code module described above, the AppleScript is not
particularly challenging to write. Its design is based on a simple premise: since the
context check above allows us to make certain that a particular version of WordPerfect
is running, the script can simply loop through the processes running on the computer
until it finds WordPerfect. It can then ask the Finder to reveal the WordPerfect
application file icon, and you can then find its coordinates and return them to
AppleGuide so the coach mark can be drawn.
Here’s the script:
Listing 5: Coaching the WordPerfect Application Icon
(Wherever It May Be)
AppleScript: wp icon script
This script assumes that WordPerfect is running. To do so, use the context check discussed above.
tell application "Finder
copy number of application processes to n
repeat with i from 1 to n
--the name is the short name
if name of application file of application process
i = "WordPerfect" then
--this is the full file name
copy application file of application process i to x
reveal x
if application "Finder" is not frontmost then activate
--remember that Apple Guide wants global coordinates
copy bounds of selection to iconsRect
set iconsRect to ((item 1 of winRect) +
(item 1 of iconsRect))
& ((item 2 of winRect) + (item 2 of iconsRect))
& ((item 1 of winRect) + (item 3 of iconsRect))
& ((item 2 of winRect) + (item 4 of iconsRect))
return iconsRect
end if
end repeat
end tell
Putting It Together
With this external code module and the AppleScript coach mark described above, it is
very easy to write a guide file to assist the office manager in verifying that
WordPerfect can run on a computer and that the correct version is installed. Having
done that, you can easily locate the WordPerfect application icon to coach the user in
creating an alias.
The guide file below actually does this.
Listing 6: The alias installation guide file
Alias installation guide file
This is the guide file in all its glory. The final section - once the alias has been created, dragging it into
the Apple Menu folder - is omitted since it should be the same as a number of such sequences in the
Macintosh Guide file. The first half of the guide file is pretty standard stuff.
#Define formats and set default. Note that the No Style formats let you
#use your word processor to set color, style, font, etc. This is useful
#for hot text.
Black, Right, false
Black,Left, true
10, , ,Left, true
#Define Prompt Sets and set default
arrow to continue", "Click the left arrow to go back or the right
arrow to continue", "That’s all, you’re done!","Do this, then
click the right arrow to continue
application", "1.0
#---------------------------below this line is specific to this guide file------------------------
#The external code module we created
#coach marks
"Make alias", RED, UNDERLINE
"Find", RED, UNDERLINE
#context checks
SHORT, OSTYPE, SHORT, SHORT, SHORT
This guide file will:
. verify that WordPerfect version 3.1.0 is installed on your
computer and can run, and
. assist you in creating an alias for it to place in the Apple
menu
#Don't ask the user to launch WordPerfect if it's already running
Do this
To start, please launch WordPerfect -- either by double-
clicking on it or by double-clicking on a WordPerfect
document.
"Oops: no WP
Do this
Select the WordPerfect application by clicking once on it.
Do this
Now create an alias for WordPerfect by choosing Make Alias from
the File menu.
Move the alias you have just created to the Apple Menu folder.
(Don’t do this in a real live guide file! Coach the user
through the process. This section is omitted here because it is
used several times in Macintosh Guide. Use the same logic as is used
there.)
Oops
The wrong version of WordPerfect is running. Either locate
another on the computer (using the Find File command) or install the
correct version.
Click OK when version 3.1.0 of WordPerfect is running.
Oops
WordPerfect is not running. Either locate it on the computer
(using the Find File command) and run it, or install it and run it.
Click OK when WordPerfect is running.
Note that the context check is used with two sets of parameters. If the correct
version of WordPerfect is not running, the Oops sequence checks to see if any version
of WordPerfect is running and displays the appropriate message (no WordPerfect vs.
wrong version).
Starting the Guide File
The last thing you need to do is to start the whole process going. In the example
discussed here, you would most likely either have a diskette with the guide file or a
folder on a network server that contains the guide file. All you have to do is start it
running.
Apple Guide automatically builds the guide menu with the appropriate Apple Guide
files for each application (and the Finder), but for solutions such as this, it is more
common to launch the Apple Guide file using an Apple event. The following script
launches any Apple Guide file:
Listing 7: Starting a Guide Gile from AppleScript
Apple Guide starter script
This script starts Apple Guide and then opens a guide file of the user’s choice.
AGStart
set theGuideFile to choose file with prompt "Where is the Apple
Guide file to open
tell application "Apple Guide
Open Database theGuideFile
end tell
Naturally you can hard-code the name of the guide file that you want to open, but
asking the user to select the guide file not only makes this more general but also covers
a potential problem. The AGStart command starts up Apple Guide in case it is not
running. Since it takes a little time to launch Apple Guide, the user interaction of
finding the appropriate file covers that time interval and prevents the script from
getting to
tell application "Apple Guide
before the Finder knows that there is an application “Apple Guide.”
Summary
While you may think of Apple Guide primarily as a help system for applications, you
can see it is far more than that. Its step-by-step task-oriented interface, combined
with context checks to keep track of the environment and the user’s actions make it an
ideal delivery vehicle for solutions like the one shown here. The branching, persistent
checks (), and Oops sequences used in the guide file in Listing 6 provide a
very sophisticated environment for the user.
When you add the fact that developing Apple Guide assistance is really very easy
(once you have a clear conception of the task and the user), it’s an important tool for
you to use in developing assistance and solutions for people.
Referenced by (2):