Again with the start using

[Richard Gaskin]

Dar Scott wrote:

> 
> On Friday, March 5, 2004, at 09:58 AM, Richard Gaskin wrote:
> 
>> 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.
>
> This is what I have been calling "custom controls."  Well, maybe custom 
> controls are more general as they might include some made from a single 
> control that is not a group.  I don't mind adapting to what other folks 
> call them.  I think a problem with "compound object" is that it 
> emphasizes the compound nature and not the single control nature.

Agreed.  "Custom control" is more useful in more circumstances.

>> 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.
>
> We have unshared field text and button highlight.  Suppose I make a 
> "custom control" that has/is an unshared image.  This needs to update 
> the image at preOpenCard.  This "custom control" might be on the card or 
> in a group or even (as implied by its capability, usually) in a shared 
> group.  There might be several on the card some nested down in groups.

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.


>> 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.
> 
> 
> 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?

...
> Suppose I make many of those meters out of needles that can be 
> unshared.  The angles/positions need to be updated at preOpenCard.  
> Suppose some of these have message machinery (use send or move or 
> sockets or...).  They might need to start this at openCard and stop at 
> closeCard.
> 
> 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've been trying hard to find ways to support custom controls in general 
> with the features we have.

I'm a big fan of seeing what we can do to empower ourselves, and 
resorting to waiting only when necessary.


>> > 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.
> 
> It would be nice if there was a policy in place that would increase the 
> 10-50-10 based on the max number use by the IDE provided support 
> libraries in its history.  Or a very easy to buy and use add-on that 
> could be used for both standalones and maybe library stacks that might 
> be loaded by a standalone.

Agreed.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com