>>>>>>I am new to COM technology as it relates to using it outside of VFP. Maybe a simple question will give me a clearer insight to the flexibility of VFP7 and COM. If I am writing a custom DLL in VFP7 for a Visual C++ client that speaks to a MSSQL backend and has been using VB DLL's to answer calls from the VC++ client to perform various functions, will I have the same functionality if the VB DLL (using ADO) is written in VFP7? If I don't, why not?
>>>>>>
>>>>>>Thanks for your input.
>>>>>
>>>>>You should have the same functionality. ADO 2.x is a COM server and VFP can use (almost) any COM server, and be one itself. It used to be that raising events was the limitation but with VFP7 I understand that limitation is gone.
>>>>>
>>>>>HTH
>>>>
>>>>No, VFP 7 still cannot raise events by itself, but if you use my EventRaiser COM you will have no problems with that even in VFP 5 :)
>>>
>>>My mistake, I think the word "raising" is the confusion here. You're right, it can't "raise" events but it does have the ability to bind to a COM server's events.
>>>
>>>Here I was thinking about the events raised by ADO, which used to be the difference pre-VFPCOM.
>>>
>>>Thanks for the point of clarification.
>>
>>Yes, EventHandler() function in VFP 7 or VFPCOM.DLL BindEvents() function in VFP 7, 6 and 5 can bind the exposed events from other COM objects, but not from VFP COM object as the latter cannot expose any events. Here you need a workaround like my EventRaiser which is a VB COM DLL and does the event rasing by the commands from VFP COM object which instantiated it.
>
>OK, I guess my simple question has resulted in a somewhat confusing conclusion, so I am asking your indulgence to clarify what I just read. Do I understand that the VFP DLL when built and registered does not expose any of its events such as would be revealed in a type library, such that I would need a VB COM DLL, which when instantiated by the VFP COM DLL will expose the VFP COM events to the, let's say, VC++ client and enable it to 'see' the dll, make calls to it and get a return value or result?
>
>Thanks for your answer and go easy on me, I am still new at this from the VFP angle.
>
>Bill

Hi Bill,

Yes, you are correct. There is no way (so far) in VFP to define the event. You may define only properties and methods.
VB can define events and then raise them with RaiseEvent command. These events are exposed by COM DLL (or EXE) and you can bind these events from VFP with EventHandler() function in VFP 7.0, or VFPCOM.DLL BindEvents() function in all VFP versions starting with VFP 5.0.
The rule here is - the receiving object has to have the method with the same name as the event exposed from COM object. Then this method will fire when the corresponding event in your COM fires.

In VFP, your VFP COM object (DLL or EXE) also instantiates EventRaiser as object property and when necessary you just tell the EventRaiser to fire up the event for you.

* Some COM method
* do something
this.oEventRaiser.FireEvent(parameter1, parameter2)
* do something else
</pre

The only trick is that you bind events not to your main VFP COM object but to its EventRaiser like:
<pre>
EventHandler(oSomeReceivingObject, oMyCom.oEventRaiser)

or for VFP 5 and 6 :

oVFPCOMDLL.BindEvents(oSomeReceivingObject, oMyCom.oEventRaiser)

Do you really care that it's not VFP itself but some little extra VB component raising the events for you? Don't think so. It is a Component Object Model after all. :)

Here is the VB code of a very simple EventRaiser:

Option Explicit

Public cEventname As String, Value As Variant

Public Event SomethingHappened(ByVal cEventname As String, ByVal Value As Variant)

Public Sub FireEvent(ByVal tEventName As String, ByVal tEventValue As Variant)

cEventname = tEventName
Value = tEventValue
RaiseEvent SomethingHappened(cEventname, Value)

End Sub

From VB, for example, you can bind events by declaring object variables using WithEvents clause.

* VB code:

Private WithEvents oMyComObject As myComObjectWhichHasEventsDefined

Try to find my article In December 2000 FoxPro Advisor "Raise Events From Your Applications", it has the detailed description of this tecnique and samples. I will have a session at DevCon on this subject with more samples, including my new Com Communicator class which allows the instant messaging through the COM object (out-of-process COM EXE, or multithreaded DLL) for client applications.