>>True enough, however, except for the grid, all of these others are containers that may have various types of objects. The grid, IIRC, can only contain columns, so I wonder why it has .objects at all.
>
>There's a good reason for that - it greatly simplifies any code that operates on a generic object, be it a builder or a runtime decorator object's method, or any recursive thing you want to use. Before introductionof .Objects for all container classes, if you want to iterate through all the objects on your form, you had to check for the baseclass of your container, and go through .pages if it was a pageframe, .buttons if it was a commandbuttongroup or optiongroup, and .columns if it was a grid, leaving .objects for just container and custom. The .objects collection makes it much simpler.

It's only a little simpler, IMO.

FOR EACH loObject in THIS.Objects

versus

lcBaseClass = UPPER(THIS.BaseClass)
DO CASE
CASE m.lcBaseClass = "GRID"
  lcObjects = ".COLUMNS"
CASE m.lcBaseClass = "PAGEFRAME"
  lcObjects = ".PAGES"
END CASE
FOR EACH m.loObject IN eval("THIS." + m.lcObjects)

IAC, it's there to be used -- when required.