>>>>>
>>>>>Looks good. My only concern would be, does it make the less readable.
>>>>
>>>>Probably not much. It is a little more code, but the custom methods in the container practically didn't change - they just call .set_oObject() in the beginning and .release_oObject() at the end.
>>>>
>>>>Nick
>>>
>>>Can you show your example with access and assign. That sounds very interesting.
>>
>>
>>A little later. :) It is not ready yet, I needed to implement this for VFP 5 and just don't have enough time at the moment to experiment with VFP. Sorry about that. :)
>
>S'okay. :) Looking forward to it.

Actually I just tested it.

I have a form with a listbox, container and a button. In the button.Click()
I call

this.parent.container.testmethod("this.cHostName")

The container has custom method .testmethod(),
.cHostname property and .access_chostname() method for it.

container.cHostName = "this.parent.list1" && reference to listbox

*** container.access_chostname() method
local loHost1
IF !empty(this.cHostname)
	loHost1 = eval(this.cHostname)
	RETURN loHost1
ENDIF	

*** container.testmethod()
LPARAMETER tcHostProperty
Local loHost
loHost = EVAL(tcHostProperty) && here is where container.access_chostname() fires
loHost.ColumnCount = 3
loHost.ColumnWidths = "20,20,20"
***

So, the button.click() passes the name of the container property which holds the reference name to the desired object.
EVAL(tcHostProperty) causes the Access method to fire, (Access method may also check for existence of the object), and passes back the object reference. Then some processing takes place, after which the loHost variable automatically gets trashed as it is a local variable

This was just a quick test that proves that it works, but I don't know yet if I am just complicating things... :)

Nick