>>>VFP doesn't sink ActiveX events - the event fires, but since VFP doesn't know about it, VFP doesn't take any action based on it. VFPCOM allows you to sink ActiveX events in VFP using VFP code - lets VFP respond to the occurance of the OnComm event.
>>>
>>>Whether or not VFP does anything, the event still fires.
>>
>>You could do this before VFPCOM with ActiveX controls, because the OLE container lets you bind code to these events. VFPCOM bought us the ability to do this with COM objects that weren't hosted in an OLE container (like any COM object instanciated with CREATEOBJECT).
>>
>>Semantics, I guess, but an ActiveX control has a UI, and if it is being used on a VFP form, it is hosted in an OLE container.
>
>No, because you can have an ActiveX control (hmmm...WebBrowser perhaps?) that has events that can be sunk with VFPCOM, but if VFPCOM is not used, VFP isn't aware of the event firing...

Every event that is exposed in the WebBrowser object is accessible through the properties sheet and fires just fine in VFP. The WebBrowser object is a little different than most ActiveX controls in that it is also host to any number of contained objects, that before VFPCOM, were not "codable". Is this what you mean?