I see. But if I meed distributed architecture and I need to have callbacks from server to client what would you reccomend?
>You need to use objects that are created as COM objects, not as FoxPro objects. There are problems with marshaling pure FoxPro types in some scenarios because FoxPro has to manage the marshalling while true COM objects (created with CREATEOBJECTEX() or a COM ProgId/ClassId) are marshalled directly through DCOM.
>
>I'm not 100% sure how this works anymore it's been so long since I did this sort of thing on remote machines. I can tell you one thing it's a configuration and administration nightmare to do this as remote DCOM operation is fickle at best. It works well once you get it figured out and configured, but gettng it there is almost always very painful...
>
>+++ Rick ---
>
>
>>Dont know, did not find anything.
>>>I do not know if this is of any help:
>>>
>>>http://www.west-wind.com/presentations/VfpDotNetInterop/aspcominterop.asp
>>>
>>>Try this is Google:
>>>
>>>pass a true COM object over DCOM boundaries Visual Foxpro
>>>
>>>
>>>
>>>
>>>>--It's better to pass a true COM object over DCOM boundaries
>>>>Anywhere I can see a code sample of that, please?
>>>>
>>>>Thanks
>>>>
>>>>>The problem most likely is THIS which is not a COM object reference. You see in order for a COM object to marshal it needs to have a custom marshaler in place and this marshaler works with COM objects and type libraries. THIS is not a COM object and VFP just creates this object on the fly then passes it. This works in some cases but more often than not you'll run into problems with this.
>>>>>
>>>>>It's better to pass a true COM object over DCOM boundaries to ensure the type information is known to both the client and server...
>>>>>
>>>>>+++ Rick ---
>>>>>
>>>>>>Here is my code (simplified):
>>>>>>*!* Create remote server
>>>>>>loServer = CREATEOBJECTEX(clsid, remoteserver)
>>>>>>*!* Send client reference to to remote server:
>>>>>>loServer.mGetCallingObj(This)
>>>>>>
>>>>>>*!* mGetCallingObj of remote server:
>>>>>>LPARAMETERS toCallingObj
>>>>>>This.poCallingObj = toCallingObj
>>>>>>
>>>>>>*!* Callback
>>>>>>This.poCallingObj.mExecuteClientCommand()
>>>>>>What do you think?
>>>>>>
>>>>>>>>Rick,
>>>>>>>>What do you mean by "explicit reference to the client"?
>>>>>>>
>>>>>>>How are you calling back to the client? If you are simply passing a reference of an object and that object is released on the client the reference may disappear. You need to make sure this instance is created as a COM object if it is to act as a proxy DCOM object.
>>>>>>>
>>>>>>>+++ Rick ---
>>>>>>>
>>>>>>>>>Catastrophic Failure usually means the server proxy has disconnected or otherwise lost in some way. It's essentially the generic remote error that COM uses.
>>>>>>>>>
>>>>>>>>>Callbacks may not work the same way as on a local machine - you need to make sure the server has an explicit reference to the client. Two way communication over DCOM is very tricky to get right.
>>>>>>>>>
>>>>>>>>>+++ Rick ---
>>>>>>>>>
>>>>>>>>>>I am getting the following:
>>>>>>>>>>OLE error code 0x8000ffff: Catastrophic failure.
>>>>>>>>>>when a remote server does callback to the client.
>>>>>>>>>>Here is the callback method:
>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>>LPARAMETERS toMachine
>>>>>>>>>>LOCAL lcSql
>>>>>>>>>>
>>>>>>>>>>TEXT TO lcSql TEXTMERGE NOSHOW
>>>>>>>>>>	usp_UpdateReadings '<<toMachine.ReadFromScanner.pcLastReading>>',
>>>>>>>>>>	<<toMachine.pnMachineRegistrationId>>, <<toMachine.pnUserId>>
>>>>>>>>>>ENDTEXT	
>>>>>>>>>>IF This.mExecuteSqlCommand(lcSql, '', '') >= 1
>>>>>>>>>>	*!* Update client monitors with new read
>>>>>>>>>>	This.poCallingObj.mExecuteCommand(toMachine)
>>>>>>>>>>ELSE
>>>>>>>>>>	*!* If SQL has returned an error, dont call Client
>>>>>>>>>>ENDIF	
>>>>>>>>>>

>>>>>>>>>>Where This.poCallingObj has a referance to the client.
>>>>>>>>>>Any idea, please?
>>>>>>>>>>
>>>>>>>>>>Thanks