von dp am 28.April 97 um 02:31:15:
From: John Dowdell
Subject: Re: MIAW Parameters & Modular Code
To: Multiple recipients of list DIRECT-L
On April 23 Kraig Mentor pursued a conversation on a tricky way to offer
protected scripting to designers. (You can find the previous conversations by
searching the DIRECT-L archives with the phrase "modular MIAW Kraig".)
Sorry for the obliqueness... it *is* a tricky handling! Maybe if I try
rephrasing it from the top? (In the previous post I was talking mainly about
D6-style behaviors, although I believe similar principles can apply to D5-style
scripts.)
Problem: How can I distribute behaviors that others can't read? I want to expose
some functions so that other designers can call them, but I don't want them to
be able to see how I do things.
Approach: Behaviors are stored in a protected MIAW which can be called from the
Xtras menu. When a script is chosen for use in the main movie, the MIAW inserts
a stub script into the main movie. When the sprite is initialized, this stub
behavior invokes a script in the MIAW as its ancestor. The result is that only
simple calling functions are exposed, and the heavy scripting remains protected
in the MIAW.
Mechanics: The MIAW holds stub scripts in its textfields, and when a behavior is
selected the MIAW first creates a new script member in the main movie, then sets
its scriptText to the stored field text. This new script in the main movie is
the actual behavior, draggable and all. The behavior's beginSprite handler asks
the MIAW to create a new instance of the real hardcore script, and then the
behavior takes this new script instance as its ancestor. The behavior can then
call upon the ancestor to do various complex things, and the scriptText Lingo is
never exposed.
It's a complex two-step, and I don't know whether anyone will actually use this
or not, but I've created examples and it does work. Here are some of the
subsequent questions:
-- "I am not clear as to whether you are suggesting that this code would be
entered by the author? Or is it somehow also set up by the MIAW Xtra?"
In that original post there were two levels of "authors": the advanced
scripter who is selling modular and protected code, and the multimedia designer
who just wants to use a drag'n'drop behavior without ever looking at scripts.
-- "Is the Xtra script to be copied done at run time or copied in during
authoring? No way to hide a copied script during author time occurs to me."
In that example an exposed behavior was created in the main movie at
designtime, and it referenced a script in the MIAW at runtime. The stub behavior
script had its Lingo exposed, but all this Lingo did was to call the real guts
hidden in the protected MIAW.
-- "Are you suggesting that my MIAW Xtra be included with the projector, an
instance created with the above script at run time, and that script is set to be
the ancestor?"
Yes, I think that's it.
-- "From the above code, it appears that the main movie is requesting a copy of
the script from the Xtra and making it an ancestor."
There are actually two scripts: the exposed stub in the behavior, and the
protected mechanics in the MIAW. The behavior calls upon its ancestor to do the
real work.
-- "If that's the case then I see no connection between clicking on a behavior
from my MIAW Xtra and setting up the ancestor?"
The only time the MIAW is drawn to the screen is during authoring, when the
designer chooses among the various behaviors offered in that protected MIAW
Xtra. When they choose a behavior, then the MIAW Xtra can create a stub script
in the main movie. When this behavior is executed, it requests that the
(undisplayed) MIAW create an instance of the real script, which becomes the
ancestor to the behavior.
No real critical issues here, and I'm almost afraid that talking about it this
much may make it more difficult than it really is... it's just that, if you're
seeking ways to market easy-to-use behaviors while still hiding the Lingo, then
there are ways to do so.
jd
D. Plänitz