>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 COLUMNx 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.

There's a way around it, but it's in code. With any container class which accepts members of only one base class (grid, pageframe, optiongrup, commandgroup - are there any others?), you can start with ...count=0, and then add objects of that base class as you like, programmatically, in the container's .init():

this.newobject("opBlue", "myOpButton", "myCtls.vcx")
with this.opBlue
...
endwith

The trouble with this approach is that you don't see these objects in design time, and their positioning is something you need to calculate. Which is a non-issue for grids and pageframes - the positioning is automatic, you only need to care of their order of appearance - and isn't too hard for optiongroups either. If it's vertical, you just set .left=0 and .top=(nIndex-1)*(.height+2), where nIndex is the button's ordinal number. If horizontal, .top=0 and you need to accumulate the widths.

I generally stay away from commandgroups :)