Again with the start using

[Richard Gaskin]

Dar Scott wrote:

> 
> 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
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com