David,

The difference in what you are doing and my approach is that I deinfe the behavior of the controls in the control classes and the form design is just assembling funtional parts. If I need to later a behavior I edit the appropriate control class, or the form class if the behavior is in the form class.

My philosophy is that if a form doesn't work right I need to debug the form without regard to the class code. If I find that the problem lies in the class' behavior then I need to shift gears and go to class design mode and suspend the form design work until the classes work as they are supposed to.

Because of this I am not interested in getting at the "class code" from the form designer, AAMF, the class code would be a distracter in debugging the form.

All this is based a situation descroibed by the following analogy:

1. In FP 2.X a command button would appear pushed down when the mouse button went down and popped up when the mouse button was released.

2. We could not see the code that did this

3. We did not care that we could not see the code

4. Why? Because it worked. If it didn't work we would be concerned.

In the analogy the actual code is out of our control as it is not our code. Well, in OO development we are supposed to do the same thing. We design classes and then when they are done and tested we design forms. While designing forms we should need to be aware of the code in the classes. If it is necessary to intimately know the code in the classes to use them then we have a class design problem. If, during the fomr design, we discover a problem with a class, then we need to drop back to class design mode and fix the class.