>Hi Dragan,
>>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

>
>Thats mainly what I do - with grids, the only place I need it. But this is not realy the use of MEMEBER*.

Sure isn't. This was how we did things before the member* properties came to be. And I still don't use them, because it's not as good as I thought I'd be. I've run into some glitches when trying to use them for columns defined in a .prg, where the column's header and textbox were also defined in the same .prg - somehow couldn't get it to work, and just reverted to the previous solution.

>For the grids I've a method that receive a Array and build up the columns from it. This runs with all the column properties I need. This is from the days where HIGHLIGHTSTYLE was unknown and the "highlighted" row was done with DYNAMIC*COLOR.

Why not - you got to have metadata somewhere. Array is as good as any other, and probably simplifies a few things. I do mine in code for two reasons: it's easy to edit, move around and generally mess with, and it's self-contained, i.e. no extra table where to keep the metadata.

>>I generally stay away from commandgroups :)
>
>I remeber the existence of such a class. Never figured out what it is good for.

It's keeping company to the poor lonely formset.