>>>>OK, so EventHandler() does not work in this case? I guess I misunderstood the new features then. Obviously I haven't tried this new function.
>>>
>>>EventHandler allows VFP to handle events raised by other COM objects, but does not allow VFP to raise events.
>>>
>>>The question is a bit moot in my opinion, because VFP can take an object reference to an object designed to raise events, and can call the agreed upon methods to achieve the same effect as raising events...
>>
>>OK, Eric, let me try and get this straight (I am having to go a little slow at this). In order for a VC++ client to be able to use a VFP DLL, it must know what events it can call in the VFP DLL,
>
>No, it must know what _methods_ it can call.
>
>I think you're getting confused between methods and events. Events aren't 'called' by separate components, they are 'raised' by the source component, and can be 'handled' by the other component. The methods of your VFP COM server can be called from any VC++ process. An event is different, and is a very specific thing in COM that amounts to a 'hook' where the user of a component can run code when that event occurs. For example, you don't call a control's GotFocus event, you place code there that should run when the control gets focus as initiated by the user.


AHA, the filament of my light bulb finally 'fired'. Thanks for the clarification. I guess the other thing that I have learned through this process is that VFP COM methods cannot involve user interfaces, such as forms. I guess the way around that is to have another VB DLL that exposes the forms, calls the VFP DLL for the hard work and returns results through the form back upstream (if the external DLL is responsible for providing some independent user interface).

Thks again,