>Thanks Matt,
>
>>Well, the only way around this I see is to define subclasses and have those added to your form at run-time.
>>
>>BTW, IMO, this is a terrible implementation of OOP development. But, if you're restricted by your environment, I understand. Been there, done that. Anyway, again IMHO, probably the best way to do this is to have a 'custom subclass' prg that gets called from the load event from the forms that need to use the classes in your SET PROC statement. From there you can programmatically sub class the objects you need and then add them in the init of the form.
>
>This is not for myself, but actually for my boss. To date I have always built custom classes visually and dropped them on to my form (I intend to continue in this manner). My boss is not happy with this approach (although I started quite a big thread up on the merits of Visual vs Programatic class definition late last week) and much prefers to code his DEFINE CLASSe's.
>
>Now that he's started off down this route, he wants to know how to do exactly what I have just been asking about, and told me to find out! This is the reason for my (unusual?) enquiry.
>
>Thanks for the advice, I will pass this on.

Steve-
Though you cannot change code at runtime, you can toggle properties. You could add a cutom property to the class that would prevent the default behavior from happening if it's value was .T. (or whatever). At runtime, instanciate the class, and set the property. If you need other code to run instead, put it in another object (the form for instance) and call that method from your custom object.