Hi Terry,
geht so.
Oh, it's not impossible to alter the name. At least if you OptionGroup is an object, not a class. So your OptionGroup class has to have BUTTONCOUNT=0.
If the OptionButton is inherited (within an OptionGroup), then it should not be renamed. You never know what the baseclass is relying to.
Anyway, I have not much code within the OptionButtons.
To me the poblem that I can not assign a value to an Optionbutton is more serious. I have values like 1,2,4,8 and end up with eight buttons for four values. But this would be an other thread.
What stopps me using MEMBER* was that it creates the object based on the classname. I've tried to use it on my Grids, but deep in it I use COLUMN
x for reference. (I know how to avoid it - but my spare time is bound to UT). This will fail if the Column is named My_Specialized_Column1.
Agnes
>Guten Morgen, Agnes. Alles gut?
>
>It annoys me that when you create an opb, inside an opg, it always ends up named "OptionX" and you can't change it to something meaningful, like opbAgree, opbDisagree.
>
>Terry
>
>>Good Morning Terry,
>>
>>>Just interested, Agnes. I gave up on trying to do what Bhav is some years ago, and made my opg class contain standard opbs. Do you know how you'd do this in VFP7?
>>>
>>
>>Difficult answer. As a read this message first, no. Now (after reading James message) yes, but now you know anyway.
>>I've never used MEMBER*. Looks like I need a second look.
>>
>>Update,
>>
>>what I found most annoying is that if I use MEMBER* it will create Objects named like MYObject1 MyObject2, based an the class name. Didn't like this.
>>Agnes
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord
Weeks of programming can save you hours of planning.
OffThere is no place like [::1]