>Hi Al,
>
>The Callback code is an example of how one could implement COM callbacks.
>
>The ADO sample in the same paper shows how a VFP app can call a COM object (ADO) to do work. While the work is being done in that server, the server can call back to the client (VFP) as various events occur. Perhaps this could be a progress indicator. For ADO, the Recordset has WillMove, WillChange, MoveComplete, etc. events can be called on a VFP client object.
>
>The Callback sample demonstrates how one can do the same thing with their custom COM server. Perhaps you are the author of a VFP COM server that does something like ADO. You have a method that does something, and you want to call back into the client for certain events (BeforeBuy, AfterBuy) so the client can take appropriate action.
>
>The IDemoEvents interface is defined in the class DemoEvents. By COM convention, the interface is the class name preceded by “I”. Thus the IDemoEvents interface has 2 methods: BeforeBuyStock, and AfterBuyStock
>
>The CCallBack class implements the interface and is instantiated. It is then passed to an instance of the COM server. Now when the COM server does its work it will call back to the client via that IDemoEvents interface.
>
>If the callback function isn’t set, then it’s set to a dummy instance of DemoEvents, which just has empty methods. Thus the calls to “This.oCallback.SomeCallbackMethod” are just calls to empty code.
>
>As another example, one can imagine that ADO was written in Foxpro (that’s not too far from the truth: ADO is based on the Fox engine).
>
>DEFINE CLASS RecordSet as session OLEPUBLIC
> oCallBack && initialize like the IDemo sample
> PROCEDURE MoveNext
> this.oCallBack.WillMoveNext()
> < do the actual MoveNext>
> this.oCallBack.MoveNextComplete(0
>
>
>ENDDEFINE

Thanks for the detailed explanation. This is the first time I've looked into using COM servers and I completely missed the "I" naming convention for the interface.

I was also wondering how this callback technique would work for "asynchronous" processing. If I have this scenario:

- a Main (client) program instantiates 2 COM servers. Server A does some scanning of files on local drive C:, Server B does some scanning of files on network drive F:. Each may take several minutes to process but are likely to cause low CPU utilization.

- in the meantime, the main program may be doing some CPU-intensive activity.

What happens when Servers A and B "call back" that they've finished their tasks, but the main program is running something else (worst-case scenario, say a large SELECT - SQL)? Do the callbacks fail? Does COM somehow queue the callbacks to be processed the next time the client is available to do so? TIA.