Hello from a Filemaker renegade

[Richard Gaskin]

xbury.cs at clearstream.com wrote:

> Rather the plug-in architecture is giving me trouble...
> The reveditscript and revselectedobjectchange to be specific...
...
> Trying to replace the revexample scripts with mine had limited success but
> RR started crashing non-stop...

Hard crashes are extremely rare in my experience, so it's hard to guess 
what could be happening there without seeing the code causing the trouble.

> I've asked on numerous occasions with no success. Entered bug reports and
> still am waiting with no solution in sight (see bug 34 which was commented 
> yesterday by Geoff as not-important... 

My guess is that it's been prioritized low because the number of 
affected users would be two, you and the fella who reported the bug. ;)

Most folks are either using messages directly (more on that below) or 
are so busy shipping applications that they don't have time to write 
their own script editor.


> ANY solution is highly anticipated...

The answer can be found on Peter Gabriel's first solo album:

   "When things get so big, I don't trust them at all.
    You want some control, you gotta keep it small.
    D.I.Y."

The revEditScript message is not built into the engine.  Where does it 
come from?  Find where the IDE gets its messages and you have the key to 
replacing IDE components....

There are two aproaches to catching messages in plugins, which I'll call 
the engine method and the Rev method.

The engine method uses the messages coming from the engine itself. In 
this case the message you're looking for is "editScript".  You can 
insert a frontScript that traps that message to trigger any behavior you 
want, such as cloning a custom script editor window, even before the 
target gets it.  You can trap any native message in a frontScript, as my 
Umbrellaman utility does for logging events (in RevNet).

The Rev method seems to be an effort to save you the step of inserting 
your own frontScript by providing a dispatcher.  This dispatcher traps 
the engine's messages and does an explicit "send" to all objects 
subscribed for them, such as plugins set up to receive them.

While I appreciate the effort that went into a point-and-click method 
for setting that up, I tend to prefer working as close to the engine as 
possible, using native engine messages as opposed to an extra layer that 
mirrors the native messages.  I don't mind writing a couple extra lines 
of code, and I think frontScripts are powerful enough to be well worth 
taking the time to learn to use them effectively.

In your plugin's preOpenStack or libraryStack handler you just include:

    insert script of btn "MyPluginsFrontScript" into front

In a button in your plugin containing the frontScript, you write:

   on editScript
       clone stack "MyScriptEditor"
       --- load script stuff into the cloned stack here
   end editScript

Whenever you encounter a messsage prefixed with "rev" that isn't giving 
you what you want, just look past it for the engine message that 
triggers it and you're on your way to total control over your environment.

For more on working with frontScripts, backScripts, and libraries see:
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com