>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.


Yes, there certainly seem to be many drawbacks, not all of which I've run into yet, I'm sure.


>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

That sure looks like the way I'll have to go. Since it's probably too late to get anything added to VFP7, know of a place to add suggestions for VFP8? < g >