creating new tools

[Jeanne A. E. DeVoto]

At 7:20 PM -0800 1/25/2002, Steve Messimer wrote:
>Years ago I created a set of objects for HyperCard that allowed users to
>significantly truncate the educational development process. Using stack
>templates and compoundObjects (like buttonField objects, button card
>objects, hotText objects, quizObjects, examObjects etc ) teachers could
>create educational titles in days rather than months.  Now that revolution
>is here I am inspired to attempt to port the code.  The question is ... what
>is the best approach. Here's a brief outline of what I would like to do.
>
>The app/plugin when invoked would display a palette of tools. selecting a
>tool would create a compound object on the target card.  For example: when a
>user selects a buttonField Object ( a button and field that act as a single
>object - bFO).  The code would create a button and field on a card of a
>target stack. The Objects would be related . When the button was clicked the
>field would show itself when clicked again it would hide the related field.
>bFOs have relationships to all other bFOs on a card... only one companion
>fld can be showing at any given time.


>1.  Should these tools be created within a plugin or as a main stack or as a
>substack? Ideally I would like these tools available to anyone who uses RR.
>I'm thinking that perhaps a plugin might be the best approach.

That sounds like the way to go to me as well. There is *cough* a deplorable
lack of plugins information in the documentation at present, but the basic
concept is actually quite simple. A plugin is just a stack you create. You
place the stack file in the "plugins" folder inside the Revolution folder.
Thereupon, it becomes accessible through the Plugins submenu in the
Development menu.

You can use the Plugins Editor window to control when the plugin window
opens (automatically at startup, automatically when quitting, or manually
when chosen from the submenu) and what type of window it should be
displayed in (modal or modeless dialog or palette).

You can also use the Plugins Editor to control whether your plugin receives
a custom message when certain standard system messages are sent. For
example, if you want your plugin to do something whenever the user closes a
stack, include in your plugin's script a handler for "revCloseStack", and
make sure "revCloseStack" is checked in the Plugins Editor. Your handler
will be triggered whenever your plugin is open and the user closes a stack.


>2.  How does RR "know" which stack to create an object in?  Does it just
>assume that it is supposed to create the Object on the card in the Active
>window?

Take a look at the defaultStack property. New objects are created in the
defaultStack, which normally is the topmost editable window (i.e. not a
palette or dialog box). You can get the defaultStack to find out where an
object will be created, and set the defaultStack if you want to make a
different stack the default (say, if you want to create an object in a
palette via script).


>3.  compoundObject IDs: In HyperCard I tracked the creation of all new
>compoundObjects in hidden text fields.  This was useful to prevent
>duplication of Object names and to help identify object components when a
>compoudObject was deleted.  I could create a separate ID generation
>script/function but it would be cleaner if I could get access to the code
>that generates IDs for RR objects.  Is there a way to do this? Other ideas?
>
>As I think about this some internal compoundObject accounting must be
>located in the stack being developed.  It doesn't make much sense for the
>plugin to do anything but generate the ID or Name.

I guess I'm not completely clear on why you need to do accounting of IDs
and names...however, one of the actions the plugin can intercept is the
changing of an object's name (revNameChanged).


>4.  Object Names:  In HyperCard I used specific characters to identify
>certain types of compoundObjects. To identify a bFO I used a terminal "*".
>This worked fine but every bFO button had a "*" in its display name.  Is the
>a way to avoid this with RR and are there any Cross platform gotchas using
>extra characters like "*". I presume that if I stick with standard ascii I
>should be OK?  Right?

Check out the label property. If the label of a button is non-empty, it
overrides the name property: the button is referred to by name, but what's
displayed is its label, which may be completely different.

Another way to go here might be to use a custom property. I assume you're
doing something like
  if last char of the short name of the target is "*" then...
In Rev, you might set a custom property of the button - for example, you
could call it "isBFO" - and test that:
  if the isBFO of the target is true then...

ASCII should be fine, but actually Revolution automatically converts
high-bit characters for the platform the stack is being opened in, for
everything except custom properties. So even if you use high-bit characters
you ought to be safe. The only caveat is for display - the Unix, Mac, and
Windows character sets overlap but they're not identical in the high-bit
segment, so you need to make sure any characters that will be displayed to
the user have equivalents on all the platforms you're intending to
distribute for.

--
Jeanne A. E. DeVoto ~ jeanne at runrev.com
http://www.runrev.com/
Runtime Revolution Limited - Power to the Developer!