On Wednesday, March 3, 2004, at 07:30 PM, Richard Gaskin wrote:
If you need access to system messages, the most reliable place to hook into them is in a fronscript.
Yeah. I was being dense. I was thinking of a library for supporting a family of custom controls. As such I was thinking of a library stack. The availability of custom controls might increase if developers can hide some part and libraries might work for that.
That's a very interesting case. When I make "compound objects" (grouped controls that act as a single object with their own properties and behaviors) I tend to put the code driving them into one library.
Thus far, the only time I've needed frontscripts for these is in development mode, when I need to update an Inspector for that "compound object" type.
It might be useful to see two enhancements:
- a lockGroup property that allows a group to act as a single control, even when the selectGroupedControls property is true.
- parentScripts, discussed for years on the MC list and with Raney so one could designate a single script to be in the message path for a class of objects but not others.
Given how thoroughly parentScripts had been discussed, I believe it's in Bugilla already. If the lockGroup property seems useful to you I'll post it there as well.
I would not heitate to describe a frontscript intended for general use that doesn't pass all system messages as a bug to be reported to the author.
If this is commonly held, then I might have some paths to success.
The implications of not passing system events in frontscripts are so potentially severe that any tool that doesn't should be limited to highly specialized usage, in which case it should come bundled with a bright neon sign notifying the user of the risks. Anything less would not be neighborly.
The only problem with frontScripts is the number available at runtime, currently limited to 10. But in practice, as often as I use frontScripts I've never needed more than three in all of the stuff I've ever built.
Well if somebody made a dozen different kinds of, say, meters, then a dozen frontscripts in a complicated application would be a problem.
Only if these meters are metering things related to system messages. Otherwise you don't really need a frontscript at all, except perhaps in development to build an editor for them that traps selectedObjectChanged to update itself. But even then, in development there is no limit to the number of frontscripts
> But if these use a single stack library and/or a single frontscript, > then the problem is minimized. At least one of the rev libraries is > a frontscript, so rev libraries add to the competition.
If you include all Rev libs you will consume eight out of ten available backscript slots. Fortunately Geoff has devised a plan to reduce that to one, so it may be less of an issue going forward.
-- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
