However, when you drop a class on a form class you are creating an "instance" not a class.

So, when you subclass the form the code in the click method of the button instance isn’t in the parent button class.

The best practice would be to have to button class click method call a method on the form. Then, your form subclass can override that method. This gives you a cleaner UI and allows you to reuse the button class rather than putting code in the buttons instance.

Sounds to me it is a bug in the purist sense as Bob Archer pointed out that the missing method code belongs to an instance of the class not the class itself.

However it may be a good idea to show all the methods in the call chain when "viewing parent code" to make it consistent with FoxPro tendency to blur the difference between instance programming and subclassing.

I ran into this problem because I purchased a framework which has a compund object (form plus dataaccess object). I then created an intermediate subclass to which I added objects and code meant to be be shared by several apps. Then I create an app specific subclass from that and from that I create my forms.

Whether it is good design or not (and it may not be), I think is a bug because the design time behavior does not predict what will actually ocurr at runtime.