Editing scripts in a standalone

Ken Ray kray at sonsothunder.com
Wed Sep 25 16:44:01 EDT 2002


> Does anyone have any specific ideas on how to deal with this?  It's a
> MAJOR issue for this project.  I was relying on the ability to update
> the program using the modules.  This was a long term marketing
> strategy.
>
> Note that the modules will be using the same code as the engine, but
> that the engine code will need to accomodate the modules.  There's no
> way to program this in advance, without the modules all being created
> before the engine is ever released.

Not exactly, Shari. You can make sure that external plug ins have the same
*kind* of things they add to the overall program... for example, in a simple
model, suppose each plug in supplies two graphics ("A" and "B"), and some
chunk of descriptive text ("C"). Then, the engine could be built to scan the
plugins folder, and if it finds any, it requests grpahics "A" and "B" and
text "C" from each one, building an internal list of available graphics and
text that will be used later in the program.

Now if it is just replacing assets in the main program, this is simple. If
you are talking about plug-ins that change what the program DOES during
execution, the way you can do it is to create "registerable" plugins, and
define certain places in the code where there are events that take place
that might be overridden by an external. For example, when I wrote the
HyperCard converter for SuperCard, the converter had a series of
custom-defined "events" that occurred during the conversion process
("BeforeConversion", "BeforeLoadingResources", "AfterLoadingResources",
"AfterConversion", etc.). The main program would load each plugin and would
send it an "InitSelf" message. Each plugin would then use this message to
initialize itself and to "register" for specific events that it cared about;
the main program would keep track of what plugin registered for what event.
Then, when the event was about to happen, the main program would "tell" the
plugin(s) that registered for that event that is was their turn to do what
they wanted to do, and program execution in the main program would pause
until all the plugins that wanted to handle the event had completed, and
then it continued on.

So in the HyperCard Converter example, I had a "PLTE Converter" plugin whose
responsibility was to convert HC external palettes (PLTE resources) to
SuperCard palette windows. It registered for the "BeforeCleanup" event (i.e.
the last event before the converter finished). When it came around, the PLTE
Converter converted the PLTE resource, and handed control back to the main
program, which then completed and notified the user.

Doing something like this makes it REALLY flexible, and at the same time the
main program doesn't need to modify itself.

Hope that was clear... if you need additional info, let me know.

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/




More information about the metacard mailing list