>>And most of all, does the tool *try* to build a calling sequence from the code to get a better picture of privates already in use ? Should be the most demanding part, but as the calling hierarchy could be displayed back in FP days, not insurmountable <g>.
>
>Yes, the Snap! tool, which then got rewritten in Fox itself (the Doc wizard, as it was named later) - but it goes through your whole project, and surely can't guess calls via name expressions and macros - and we'd have to add bindevent() calls to that, just to make things more interesting. And, yes, .method() calls in with/endwith blocks where the object is a local reference to our class addobject()ed to a container object. I'd like to see that AI which can catch that :).
>
>Getting spoiled, aren't we? :)

H"BackSpace"Well, I guess I was born that way. Endurance came later (probably helped by a stubborn streak).

More on the point: which situations do you need to check ? If you are working with vfp sources the only thing to check for would be missing/forgotten local declarations, as all global/private vars should be intentional. If also scope naming rules were adhered to, chances for damage from once forgotten local should be minimal, as other locals are protected by *their* local definition.

If you are working on legacy FPx code, the problem is to decide which private variables should be considered "local" and wich variables are *used* as privates further up the calling stack. So it is helpful if at least the "usual" calling paths are covered, without macros and similar methods.

regards

thomas