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

Both. IOW, I didn't have the time yesterday, having spent most of the afternoon in the attic with a hand-drill :). To really engage in some development here I'd rather take some serious time. The code looks simple (and should be), but it takes time to make it simple.

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

And now that it's extracted from the framework, it's a good candidate to make it as general as we can.

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

Much longer. It's been a while since I wrote my class, and I remember I've hit some problems (tough not exactly which ones, and whether they were in just drilling down, or later when extracting properties of the members).

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

I'm at VFP8 still - we have a general idea that we should switch to VFP9 soon, but don't hold your breath. Since I'm not working for a software company, we're slow in adopting new things.

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

That's the contradiction I indicated here - how general can it be if we limit its scope.

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

Of course there's potential - I just think we have a difference in opinion here. I thought the drilling would be handled by the class as is, and handling a member object would be left to the hook method - which any user would then have to write in a subclass. I did not see the end user having to modify the drilling itself. Now if drilling needs to be modified somehow (to circumvent the circular references, or to skip COM/OLE objects, for instance), then this is something different from what I had in mind.

My class was just a way to make it simple. I wrote it to serve some of my needs (particularly, to have a full dump when debugging, with not just (object), but a full listing of properties). I have cured myself of programmer's vanity long ago, and I don't mind if anything I do becomes just a piece in something else. We're talking here of what we want to make of this - how far should it go, what should it do etc. Just tossing ideas. Nemo' se nerviraš, bre :).