I would not recommend subclassing the OCX directly. A). It places the license file into every VCX or Form you drop the OCX directly into B). as well as the GUID C). from what I have been told by several OCX vendors the design specs for OCX's are such that subclassing of the OCX was not accounted for, it causes problems in some areas. I have never done it so I don't know. I subclass my containers.

If the vendor changes the GUID or the license file you do major problems everywhere. I have one friend who describes this kind of thing as sprinkles as in Rat Droppings. Its a messy design if you ask me. As I understand it VB places the License and the GUID into one place in the project not everywhere.

I was talking to an OCX vendor last night Bennet-tec. He made a good comment. You don't have to break up Microsoft into more than one company, they already act that way.

I would like to see an initiative whereby we as a development community develop a public domain framework for this kind of thing for VFP. I would have a whole lot to contribute. My fear would be that 7 fixes all of this and the framework need would go by the wayside like genscrnX. If it does not maybe it will be a good idea.


>Ron,
>
>One of the unique things about VFP is that we can subclass ActiveX controls and use our subclass. You could put all that custom code in your subclass. There are problems though when versions of the ActiveX change, but you may have enough control to prevent that from being an issue.
>
>>I have a good clean set of wrapper classes for my Active X's. I drop container objects on my forms the containers deal with the Active X's. The only problems is DBI's pak has 54 controls. I have some editor macros that allow me to easily deal with building the methods at design time. All the events in the active X controls are back hooked into methods in the container. I have 13 controls wrapped with anywhere from 60 % - 90 % of the functionality dealt with in each control. It is very tedious.