George

>I believe that this is purely a matter of design and really has nothing whatsoever to do with which is inherently better. Afterall, there's nothing to stop anyone from creating a bloated visual non-visual custom class.
>
>I don't believe that it's a matter of cohesion, applied at the class level.

Following on from that rather interesting discussion, my boss is developing using DEFINE CLASSe's and I am building everything visually. I think that the upshot to all of that 'was each to their own'.

However, an interesting situation has now arisen. Paul now wants to use the same progamatically defined class on serveral forms. This class has a custom method with code behind it. On some forms he wishes this code to be fired when he runs that method. On others, he wants to overwrite that with form specific code. When doing this visually, I would select the custom object (on the container), then double-click on the method in question and key in my code.

How is this done using the programatic approach? I actually started another thread on this subject, but I didn't really get to the bottom of what is going on here. The outcome of the thread I started was that you would have to subclass your custom class in each of the forms that required the modification in behaviour. If this is the case, it would then follow that when I drop a custom class (or any class for that matter) onto my form and start changing properties and methods, I am actually causing Fox to subclass my class for the duration of that form. I previously considered this to be an 'instance' of that class.

Could you possibly offer any insight into what is going on here i.e. instances and subclasses. I thought that I understood exactly what was going on here but now I'm not so sure all of a sudden.