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