On Tue, 27 Jun 2000, Brian Lloyd wrote:
The 'selection' and 'multiple selection' properties are really built with the idea that you use another property *of the same object* (rather than an acquired value) to bind the selection to. Your change works for your case, but if you try to bind to another property of the same ZClass you'll find that in your management screens that your selection property will fail (because it is looking in '_' for the value, which is the wrong place to look if you are expecting to find the value as another property of the same object.
It used to work both ways. I know because I first implemented a selection property with another property on the same object, and later moved it to a property on the root. I did this because otherwise my custom Product add method couldn't access the selection value property that was on the ZClass property sheet. (I think I could probably figure out how to make that access now, but then I couldn't). Anyway, the point I'm leading up to is, if you ignore implementation issues, isn't restricting the value field to being a property on the same object being unecessarily restrictive? Surely there can be cases where you want the value field to be acquirable. Of course, there should be a way to specify that it be the same, for cases where you *don't* want acquisition to work. --RDM