>>Yes I can think of more, ie: Control, DataEnvironment ... You might never know what the next version of VFP would have as a container type class.
>>Cetin
>>
>
>As I provided for Option/Command group I will add provisions 4 Control & DataEnvironment objects as well, by adding few more case statements.
>
>We can talk about me overlooking or simply *deciding* not to include some object types (like those dummed formsets) but I don't see it as conceptual problem for this mechanisam.

I think you really don't see the problem :).

You're trying to make a general practice recurser class, and then take a specific decision to omit some classes from being drilled down. That sort of filtering may be decided upon somewhere downstream, in a specific subclass. But you can't be both general and specific at the same time, and a primary parent class is, IMO, the place where you want to be general.

So I think Cetin got your idea better than you did :).

BTW, the worst omission in that list is Custom.

On the other hand, one decision needs to be made in any recurser class - shall we drill into COM objects or not? I've had trouble when I tried, so I specifically skipped that part, i.e. if it's one of them, do nothing. Their properties are sometimes inaccessible (unless they have a property-get method exposed), their object model is sometimes heavily crosslinked (in Excel automation object, everything is a member of the Application object, and everything has an Application property that references the top object - you can recurse down that endlessly), and they're a PITA to recurse.

With Fox objects it's pretty simple - you don't drill down the .parent - but what if you have some object property that has an .oDad property pointing to the "parent" object (though it's not really its parent, it's not contained, it just has this.oProperty.oDad=this). It'd be very simple to build such a thing, or even build a circular reference. So... we have some limitations here that we need to think of.