Again with the start using

[Dar Scott]

On Friday, March 5, 2004, at 12:26 PM, Richard Gaskin wrote:

> In that case your library isn't interested in all preOpenCard messages 
> but only those occurring in its instances, so maybe a custom message 
> is in order -- in your group you could write:
>
>   on preOpenCard
>     libDarObjectInit
>     pass preOpenCard
>   end preOpenCard
>
> ...and define libDarObjectInit in your library.

Even if objects pass preOpenCard, a group is--in general--not in its 
path.  Custom controls would typically not be backgrounds.  It is sent 
to the card.

I am considering two methods for controls and one for libraries.

1.  For Libraries:  The libraryStack handler for a library stack of 
"Dar's family of library stacks" that needs a bunch of messages will 
check the front scripts for "Filter for Dar's family of library stacks" 
and install or upgrade the front script as needed.  The front script an 
any of xxx in that bunch of messages will darLibraryStackXxx and then 
pass, of course.  Each one of my libraries that uses darLibraryStackxxx 
will pass darLibraryStackXxx.

2.  For Custom Controls:

A.  This uses #1 above.  The library stack for all the meter controls 
will get the darLibraryStackPreOpenCard and scan all controls for the 
target card for meters and send openMeter to each one.  The problem is 
that the library stack for knobs and the library stack for picutures 
and the ...  will all scan for for groups in the target card.

B.  The supporting library (or maybe, somehow, the control itself) will 
install a front script that sends openDarCustomControl to all groups 
with custom property isDarCustomControl being true.  The message either 
is handled in the control, converted to a library call or drops down to 
the library.

>>> - a lockGroup property that allows a group to act as a single 
>>> control, even when the selectGroupedControls property is true.
>> Yes.  As we (list) discussed earlier, there are different styles and 
>> I've been thinking of adding a brief thought to that.  I've been 
>> trying to collect methods to protect the using-developer from 
>> breaking "compound objects" and maybe turn lemons to lemonade and 
>> exploit selectGroupedControls.  Maybe there can also be an 
>> "effective" or other keyword modifier for "number of" or layer 
>> referencing that does not penetrate these.
>
> Agreed.  Feel like posting that to Bugzilla?

I don't mind.  However, I do have lots of suggestions in.  Some are off 
the wall.  I wouldn't want a good idea to get lost in the shuffle 
because it is viewed as just another one of Dar's wild ideas.  Let's 
bounce it off the improve list.

>> Based on your earlier advice, I think I have a way to have my 
>> libraries or controls that need certain messages to use a couple 
>> common frontscripts for all controls and libraries in the super 
>> family of my controls and libraries.
>
> That's how my libs work, but I generally require few frontScripts.  In 
> the absence of a greater number of frontsccripts, you could use one as 
> a dispatcher, trapping a variety of messages for multiple libraries.  
> It does complicate things for distributing them to work independently 
> in others' stuff, though.

I would think this would make them work better in other's stuff.

Dar Scott