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