Again with the start using

[Dar Scott]

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.

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

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

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

I am coping with stack libraries, so this is not needed for me.

There is a bugzilla request for encryption of custom control scripts 
and this is probably a workaround much of that.  If most of the scripts 
are in the library then the custom control exposes less.  Many (most?) 
developers will produce more custom controls if they feel they can hide 
insides and productize.

There is a little problem with making sure all the support pieces are 
put in the right places when a custom control is pasted or placed on a 
card.  I'm not able to make newGroup work for this.  I'm currently 
thinking that a plugin or custom control catalog might be needed for 
this, but folks might still copy and paste controls.  Another approach 
is the documentation approach "When using this control, the library 
stack 'Dar's Meter Support' must set as a library with the 'set using' 
command."  The technique of having a hidden group with background set 
on the first card needs a method to place it there.  So...  For me, a 
copyGroup message (like newGroup) would make a parent script unneeded.

> If the lockGroup property seems useful to you I'll post it there as 
> well.

It would be.  I'm not sure of the name.  There might be other related 
custom control (aka "compound object") goodies that are needed and the 
features might be coordinated.

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

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.

Another possibility is openControl or openGroup etc. but this might 
have a bad impact on cards with a zillion controls; I haven't pondered 
on all the implications.  The openGroup might be less of a load.

I've been trying hard to find ways to support custom controls in 
general with the features we have.


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

Dar Scott