Hi Dragan,

Cannot write much as I hv to go, but to tell you that (after some struggle) I found the way to drill down forms datanevironments as well, so what is left now are famous FormSets :)

I come across some funny behaivior with _screen and _vfp collections , will talk to you more about tmrw :)

I disregarded Control Object because it is not like regular containership.
There is no way to penetrate in there even if you want to do it manually from the form.


Pozdrav :)
Srdjan




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