>I think you really don't see the problem :).
>
Hi Dragan,

From your message I cannot determine wheter you are interested in collaborating on this small code project, or just to hv little thread chat about general recursion problems.

Code I sent was pooled out fm my framework where was serving specific
purpose(s), according to my framework needs, and remodeled in order to
start drill down from point - higher then form.
That is why some things are ommited (they were not there at first place).

It was/is just an open code-idea that I invited you to co-develop into something more usefull, since you were already involved with such issues.

To fulfill ALL missing VFP NATIVE object types (closing with VFP6) , will take just a little bit longer then writing this message (and will be done right away). Sorry guys, but I cannot see any problem/point here after that. Except of course VFP7-9 period which I cannot handle at the moment.

Regarding COM,OLE's , cross linked objects etc , my opinion is that they are out-of-scope here, if we are trying to keep it general.

Class DOES access them as whole and passes them to 'with_object' method, so I wld rather let user write their own particular drilling/handling for particular purposes. Or simply ignore them.

My whole idea here is revolving arround that. Drill down all / or particular containership objects - and pass them to specific method.

I see some potential in this concept, and will work further on it.

Thank you for your time guys
Rgds++
Sergio


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