>Nigel,
>Do you check for the existence of oParent when you make calls to it? If not, why do you need to check for the existence of oParent.oChild? If oChild is that important to your application, then I would make it required to run your application. If oChild doesn't instantiate, then oParent doesn't instantiate. If you do check, what's the difference between checking for that and checking for oChild?

>type("oParent.oChild") = "O"

>
>Having said that, I might go with the Procedure approach because you could added functionality built into it to handle the Datasession issues that exist between object calls. Calling a procedure does not change the datasession so you could add code to retrieve the current datasession, if needed. You could pass this to oParent.oChild. If you went the oParent.Method approach, you would have to pass the datasession ID from each oForm.Control call.
>
>Performance-wise, I really don't think you would see a perceptible difference.
>
>Just my $0.02.
>

Larry,

oParent is the Application Object - it has to exist for the app to run. oChild will exist but may not be populated by the object. If this particular calculation is not required in a certain installation, it will not be instantiated but attempts will still be made to call it.

DataSession is not an issue here as the method will be doing calculations based on parameters received. Also, its a VFP DLL built on a Session object so it's private anyway.

Interesting comments though...