Again with the start using
dsc at swcp.com
Fri Mar 5 13:58:54 CST 2004
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
> 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
>>> - 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.
More information about the use-livecode