9.1) How do I do code resources/extensions/external functions, much like HyperCard XCMDs only for my 68k app/extension? (Standalone Code & Trap Patching - Mac Programming)
Description
This article is from the Mac Programming FAQ, by Jon Watte h+@austin.metrowerks.com with numerous contributions by others.
9.1) How do I do code resources/extensions/external functions, much like HyperCard XCMDs only for my 68k app/extension? (Standalone Code & Trap Patching - Mac Programming)
Here is what you need to do:
Define a storage location for the plug-ins. such as, for an application
called Foo, a folder called "Foo Pouch/ PlugIns/ Modules/ Tools/ Etc",
which your installer creates, and which you search for in the same
folder as your application, the preferences folder, and the System
Folder (for System 6 (no preferences)) the name of the pouch folder
should be in a 'STR ' or 'STR#' resource for easy internationalization.
Next, define a resource type to hold your plug-in exectuable code. You
should allow any resID number, since some development systems have
restrictions on which id numbers can be used for multi-segment code
resources.
Decide whether you will allow multiple code resources per file. For
example, Photoshop lets you bundle an import resource, an export
resource, and a filter into the same file, each is its own resource
type. It uses the resource name to tell the user, so each has its own
name.
Decide on the user interface to plug-ins. Commonly, at program
start-up, you scan the pouch and collect all the files of the correct
types. Then you scan for appropriate code resources, then put the names
of the resources in the menus. You can also use the file names, or run
the code resources and ask them for the correct name.
Decide on the calling convention. MPW likes to pass parameters as
longs, and pascal development systems usually can't generate C
interfaces, so your best bet is to have the entry point of your code
resource be something like:
extern pascal long PlugIn(long selector, CallbackPtr callback,
long param1, long param2, long param3, long refcon);
where params 1 through 3 will have specific meanings depending upon
which function selector is asking to be performed.
CallbackPtr is something like this:
typedef struct CallbackRec{
DrawFunc erase;
DrawFunc paint;
}CallbackRec, *CallbackPtr;
where DrawFunc is something like:
typedef pascal void (*DrawFunc)(Rect *);
This is the place where you define services that your application will
perform when asked to by the code resource of the plug-in.
You'll need to define a bunch of selectors for what you want the plug-in
to do.
You should definately give the plug-in an Init selector, and a dispose
selector, and have Init return an error or a refcon, which will be
passed back to the plug-in on each call, so the plug-in can have some
persistent storage. You should definately set the CurResFile to the
plug-in's file while it is running, so it can easily get at any
resources it needs.
The Init selector should pass the interface version in param1 and the
program version in param2, so that the plug-in can cope with different
versions of your program.
The actual call to the plug-in looks like:
*code*
h = GetResource('PLUG', 1);
HLock(h);
xh = StripAddress(h);
((PlugInFunc) *xh)(kInit, callbacks, kInterfaceVer1, kProgVer1, 0, 0);
HUnlock(h);
*end*
The StripAddress is important; if your app is running in 24bit mode, the
resource handle may contain tag bits and you don't want strange things
to happen if the code resource switches into 32bit mode (which QuickDraw
may do, incidentally)
Exactly how you structure your calling conventions is up to you; there
is no accepted standard (except for HyperCard XCMDs, but that is
probably overkill for you).
Continue to:
My Books
