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.

Yeah, I still have a method MyInit_V8 on my grid class that is of no use.
>
>>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.

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

I disagree. ::) I do not use formset in my apps but it is still in use. (You can't avoid)

Open a form in IDE, point the mouse to it
in command window enter

loA  = SYS(1270)
?loa.Parent.baseclass

see?

Agnes