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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
