>MS is promoting VFPCOM primarily to help with ADO, but it actually has a lot more use than just that. For example, I've built an SFTreeViewController class that automatically receives events from TreeView controls. The cool thing about this is that I can now drop a plain old TreeView control on a form (or even instantiate it programmatically at runtime) and not put any code at all into the TreeView. The SFTreeViewController object grabs all the TreeView events and does things (like automatically add children to a node the first time the node is expanded).
>

Ok... so, let me see if I got this straight...

In Mere Mortals Kevin has a TreeView wrapper that uses your ActiveX loader to load the TreeView into a container that you put on the form. But, what actually gets added is a subclass of the TreeView that is in a .PRG file. The subclass calls events in the Wrapper which is where you write your code, so you can have several instances of the wrapper with differnet code.

The difference here seems to be, that I create a class (which is not a subclass) of the TreeView. In that class I create Methods the mirror all the Events in the TreeView. When a treeview event fires it will also fire that event in the class I have created as a BindEvents class.

But, I assume there are COM objects that you can not drop on a form and get to the events in the property sheet? Is this correct? If not, maybe I am missing the advantage of not putting the code in a subclass or instance of the COM Object/Control?

BOb