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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
