>I think I'd put all the customization code in helper methods of the container that holds the ActiveX. That way the only code you have to put in the ActiveX methods are calls to your container helper methods. This would minimize duplicated instance code.

I am not sure that I know what people mean by helper methods. I have never been clear on this and I have read quit abit about design patterns (Own the Design Pattern book and CD and have read all of the articles on FoxTalk). If this simply means that most of my code goes into a method in my container then that is what I am doing 99.9 %. the only code I put into the activex method itself is for events and that is a call back code to the corresponding container method. I ended up naming my events in the container with a prefix of 'e' as in eClick. I could not see far enough ahead to see if I ever needed the click event of the actual container for something else plus some controls have other events. I wanted all of the events in the container to group together and seperate from methods whose prefix is 'm'.


>I'm not sure you could herd too many VFP developers in the same direction, especially with 3rd party ActiveX controls. This discussion would make for some great articles over on the...

I agree.

I am torn. This whole thing is more tedious than hard. Very time consuming. I have thought about creating a product for DBI controls for Foxpro and selling. But I do not really have the time. I could put the work into the Public Domain as a form of advertisement, but I am against the somewhat Rock Starishness of all of that plus it may create too much not paid for activity. As a business man if I am going to be benevolant to that extent then I will go help some charity who is doing really great work.

I have the thing down pat. Its fast and clean and very dependable. I have countless hours into it, some paid for by billable hours, some paid for by not billing and some paid for by my own private Friday night parties at my computer.