David (and Bret),

Making a "contract between objects" has to be just some fancy terminology/footwork to get around this **problem** of VFP (let me call it the 'object addressability problem'. It is way beyond my limited capabilities, but I have to believe that it *can* be solved elegantly if the right heads are applied to its resolution.

And David, I thought that the whole premise of both Windows and Objects *IS* the passing of messages to/fro. I cannot see how this would "break" encapsulation.

I can imagine that frameworks will be significantly different once the 'object addressability problem' is resolved. And so will classes generally, as well as their overall usefulness.

Cheers,
Jim N

>Bret,
>
>>If I understand correctly the advice Jim Booth gave me, frameworks should be built that way, with the buttons referring to methods in base form classes, making what he called a "contract between objects." TASTRADE works that way.
>
>Yes, it's just the interface that you've designed the two components, your form and button group, to use to communicate with each other. Objects talking to each other basically breaks encapsulation. But non-trivial objects are pretty useless unless they can communicate with other objects. *s* You encapsulate what you can and define interfaces for everything else.
>
>>My nav buttons use methods in my button bar container class, which can be neatly dropped on a form, WIZSTYLE-style, as someone here suggested. But if I want to use these buttons in a toolbar, I will have to start over.
>
>Not really start over, you just use _screen.ActiveForm instead of thisform.