>>That's not quite how a call back works, nor does it accomplish the same thing. There are many methods for a server process to determine what code the client runs, but allowing the server process to actually invoke the routine is what's needed. Your code sample simply invokes a synchronous method in the server and uses the return value to decide which procedure to call, but does nothing to determine when it should run.
>
>A call back works more like ON ERROR (i guess). Larry forwarded a URL to VFPCOM - I'll check that guy out. Thats what we need, an ON EVENT service!!


The method you mentioned means that the client will have to "poll" the variable and act when it changes. This is inefficient in event driven interfaces. What we need is VFPCOM or an integration like VB has where you can create an instance "with events".

Then you fire your call to the server and continue without waiting. When the reply comes back the client will be interrupted by the server and can then act on this advice.

Something similar to adding a MSCOMM32 OCX to your app and waithin for the ONCOMM event to fire telling you that data has arrived at the designated comm port.

I could do it by passing an instance of my form to the server along with the name of a method on the form to callback int when the server got the data I wanted. But with VFPCOM and BINDEVENTS more is possible and I do not have to pass these params for a callback to work.

Bernard