...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 editScriptWhenever 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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
