>I would do it the first way.

Furthermore:

- if I need to call several methods of oApp's member, or it gets called inside a loop, I'd get a local reference to that member, and then run its methods. There's the speed benefit, as Fox doesn't have to navigate the containership hierarchy (and in case of oApp it may be large) and there's the development benefit - the local variable may be declared properly so Intellisense may pick it up.

- having _access methods to get a property of a member would be too much code for little gain, and, as Craig said, a potential source of errors which would take longer to debug

- the only reason to have such delegating code is legacy code - you noticed that there's a group of related tasks that oApp is doing regularly, and you decided to extract those into a separate class, making oApp a bit thinner and easier to read. Now all the calls to the old methods would need to be hunted down throughout the project? Nope, the interface remains the same, it's just that oApp.DoSomethingAboutX() now contains only the line with oApp.Xhandler.DoSomething().

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