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

I buy the ideal, but in practicality, I think sticking to this approach dogmatically is hampering. Hiding is great if the black box behavior is completely (and I mean completely) specified. During development it would be nice if all of the specs for your black box components had complete descriptions but in my experience, you use the code to document itself during developmen. That means you need to look inside to see how something works. I understand the pitfalls of looking inside...you run the risk of depending upon implementation details that are strictly not part of the interface. The upside is that you can figure out how you are misusing an object by observing what happens inside it.

A really good example of what I mean is the VFP baseclasses themselves. Their interface specs are disparate and incomplete (or I just haven't found the right book yet). I'll bet that if could look inside them I could figure out for myself what's going wrong with my (expletive deleted) combos without having to run to UT every time I have a problem. These baseclasses clearly do things in the background that effect properties I can see, but I am frustrated in all attempts to search down the reasons for what I observe.

For example, I currently have a problem with a combolist (new thread) that is reverting to a previously selected list value. I'll grant you that I am probably abusing the combo in some way it was not meant to be used, but if I could trap on the code where the value is reverting (which I have determined to be definitely inside the black box) I would likely be able to figure out what I'm doing wrong, externally. In fact, I claim this is the quickest way to find my problem. But the Gods of Hiding must be served, so I flounder. This is very frustrating and an example of where dogma goes too far.