selObj from a palette stack

[Richard Gaskin]

René Micout wrote:

 > I have my own plugin (rmTools) and I can see what you are writing
 > in your last message, but what is better ? between :
 > revMoveControl <> moveControl
 > revResizeControl <> resizeControl
 > revSelectedObjectChanged <> selectedObjectChanged
 > etc...

There are also some mirrored properties, like the cRevLoadInfo["mode"] 
property which does the same thing as the built-in style stack property. 
  The mirrored properties have mystified me since they were introduced 
into the IDE; I'm a big fan of just teaching people how the engine works 
and how to use it well.

The messages, however, make more sense in a world where third parties 
can't be trusted to always pass frontScript messages.

Without either your stack having a frontScript or the IDE trapping 
relevant messages and then sending them to your plugin stack, your 
plugin stack would have no notification of those events at all because 
such message are sent to the target, outside of the message path of your 
palette.

In the olden days, before the IDE introduced the plugin management we 
have now, we handled this in our IDE plugins the same way we'd handle it 
in our standalones:

Insert a frontScript when the plugin stack opens, remove it when the 
plugin stack closes.

This is simple, provided the IDE vendor encourages people to understand 
frontScripts if they want to write plugins.

It's also robust, provided the IDE vendor informs the plugin developer 
of the importance of passing messages handled in frontScripts.

Plugin developers will have to learn at least one additional thing 
anyway, so it doesn't really matter whether you teach them how to use 
the message path well or how and why your IDE alters the message path to 
create the mirrored messages.

But the implications of mistakenly not passing messages are severe, 
since of course messages are the life blood of the engine - cut them off 
and expected behaviors die, possibly raising support costs when folks 
use a poorly-written plugin and wonder why their IDE stopped working.

At this point the mirrored messages and properties are here to stay, so 
if you're making stacks to be used only as IDE plugins it doesn't really 
matter whether you use them or not.

But if you may want to use your plugin in a standalone, you might prefer 
the frontScript method since it's how the engine naturally works.

The only downside to using frontScripts is the current limitation that 
you can only have ten of them in play at any given time in a standalone. 
  This is a function of the scriptLimits, which don't apply to the IDE 
but do apply to all standalones.

If you need a lot of frontScripts you could consider handling those with 
a single generalized trap like the IDE does, dispatching those messages 
(or some mirrored form if you prefer) to any stacks or other controls 
that need updating which may be outside of natural message path.

But then again, if your app needs more than ten auxiliary windows open 
at a time, you have more of a concern about UI cleanliness than 
messaging. ;)

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys