And Dave has demonstrated EXACTLY my problem with this. The simple fact is, I am creating grouped widgets, which I have differently named components within, which I would like to be able to address.
Mark, your example also demonstrates the power of same named instances of object. I guess it all boils down to each of us trying our best to create reusable grouped components, each with the same codebase. A most difficult task. For instance, take altFldHeader which creates column headers for fields. ( go URL "http://www.gadgetplugins.com/altplugins/altFldHeader.rev" ) While it's been stable now for years, modifying old altFldHeaders still is a problem as each instance has all of the code embedded in the group. The same is true for many of my so called 'objects.' A benefit of this approach is it's easy to do exception programming and track code as well with everything being neatly packaged in a group. A big drawback is when you want to modify the codebase, you have to replace each group, especially if you end up adding a new control. Separating the 'object' into a GUI library group and a background library has it's own set of problems as well. You need to carefully track what libraries are still being used. For instanec, they have to be inited from a startup handler, so now you have at the minimum 3 different places for custom object 'pieces': the library stack script, the GUI control group, and a piece of init code in startup. You also need to be very careful using 'the target' and if you have other system handlers, you'll need to make sure they don't interfere, as they're called ALL THE TIME, instead of only when needed. I'm not crazy about this approach, unless you're coding something like libURL. (Note: this could be simplified a bit by inserting the script of the object into back, but the severe limitation on numbers of these makes it a poor idea. All you need is 10 altFldHeaders and you've used up all your allowed control inserts). Perhaps a dynamic pseudo-instancer scripted from an installer might be an interesting way to go. I don't know, I guess waiting until we get real objects is the best way to go. -Chipp On 1/20/07, Dave Cragg <[EMAIL PROTECTED]> wrote:
I assume any restriction on duplicate names would only apply at the same level within an object. Otherwise we'd have trouble with re- usable widgets made of grouped objects. For example, two "table widgets" on the same card should be named differently, but presumably not their component fields/buttons/sub-groups/etc. I.e. both tables can have buttons named "header". Dave _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
