Hi Fred,

I tried these ideas a long time ago and found that they didn't suit my needs. The other problem I used this for is to have a builder fire when you close the designer. You can use the Destroy() event of the object that is loaded. By now, you have discovered the drawbacks yourself:

It's only executed when the class definition is loaded the first time. After that you need either a RELEASE CLASS or CLEAR ALL to get rid of it and have VFP evaluate the expression again. At least when I tested it (VFP 3, I believe), it didn't always work. Not only depended it on the class library being loaded, but also simply did nothing in some subclasses.

I still think that the builder lock is the way to go. When VFP launches a builder, it does so by calling the Builder app. The Builder.APP that ships with VFP then checks the builder property (you need to add that to your form). If there's a builder in there, it loads it, otherwise it tries to find a registered builder for the baseclass. What you need to do are two things:

A) Add a builder property and make sure that they contain the builders you want to fire up. Detailled information can be found in the Microsoft KB and also, with VFP 6 you get the source code for Builder.APP.

b) Either alter Builder.APP or create a new program. This program checks if the builder should be launched, or not and passes the request on to Builder.App or ignores it. You can use a property in the class to indicate whether a builder should be launched automatically. Finally, you need a replacement for the normal builder call so you can distiguish an automatic builder call from an explicit one.

Christof