From my point of view, providing an interface to access methods or properties of the child objects has the following disadvantages:

1) First of all, in VFP you cannot enforce the developer to use the interface, he will always be able to call the object properties directly. So in any case, if you create the interface, you cannot rely on the situation that this is the one method always called.
2) It is a lot of overhead: each time you need to extend an object, you have to extend the oApp class as well. Is this really the responsibility of the oApp class that you are extending?
3) It does not solve your problem: if you want to have intellisense when you call the methods or access the properties, you still need to add those two lines of code:

LOCAL loApp AS AppControl OF Application_Control.vcx
loApp = oApp
loApp.DoSomeMethodInMemberObject()

Remember: the only way to avoid bugs and errors in your code is to always make use of intellisense!

4) It is not typical in most applications. Automation class models strictly divide responsibilities:

loExcel = CREATEOJBECT("Excel.Application")
loWorkbook = loExcel.Workbooks.Open("c:\test.xls")
loWorksheet = loWorkbook.ActiveSheet
loWorksheet.Cells(1,1).Value = "testing"

Of course you cannot find a method like

loWorksheet.DoSetCellValue(1,1,"Testing")
*-- What makes sense is:
loWorkbook.Close()
*-- instead of
loExcel.DoCloseWorkbook()

But I can imagine other developers have a different take on those things.

>Christian,
>
>I will try that 'trick'. Thanks.
>
>So, I take it that you also prefer the first option. What are the pitfalls of using the 2nd option, that of providing an 'interface' instead of allowing 'direct access' to the member object?
>
>Dennis
>
>
>>You are correct, this is a limitation of using object references in VFP, because you don't know the type.
>>
>>There is a workaround for this that you can use:
>>
>>

>>LOCAL loActiveUser AS UserBiz OF Security.VCX
>>loActiveUser = oApp.oActiveUser
>>loActiveUser.SomeMethod()
>>

>>
>>It's more lines, but makes the code very easy to write and read.
>>You can create intellisense shortcuts that provide you with the first two lines. When I need to do someting on the ActiveUser object, I type "ACTIVEUSER" in the method, and the instellisense code extends it to the first two lines in my example. Then I can continue writing the code referencing the object knowing the type.
>>
>>>Craig,
>>>
>>>So, which means, we have to provide info on the Properties and Methods of each member object?
>>>
>>>Dennis
>>>
>>>
>>>
>>>>the first.
>>>>
>>>>>Hi Experts,
>>>>>
>>>>>I have decided to have an Application Object, with its associated 'member objects' attached to it, like so:
>>>>>

>>>>>oApp = CREATEOBJECT( "myApplication" )       && also instantiates oMember1, oMember2...
>>>>>

>>>>>My question is, should other objects be able to 'directly' get hold of the member objects like so:
>>>>>

>>>>>oApp.oMember1.SomeMethod()
>>>>>oApp.oMember2.SomeOtherMethod()
>>>>>loMember1 = oApp.oMember1
>>>>>loMember1.SomeMethod()
>>>>>

>>>>>Or, should the Application Object provide an 'interface' to them, like so:
>>>>>

>>>>>oApp.SomeMethodofMember1()     && will call This.oMember1.SomeMethod()
>>>>>oApp.SomePropertyofMember1     && will access This.oMember1.SomeProperty
>>>>>
>>>>>oApp.SomeMethodofMember2()     && will call This.oMember2.SomeMethod()
>>>>>oApp.SomePropertyofMember2     && will access This.oMember2.SomeProperty
>>>>>

>>>>>Thanks In Advance
>>>>>Dennis