>I can see the advantage of having nav button classes which contain code referring to methods in the form. Those buttons then >don't have to be used with a certain container, but can then go in a toolbar. However, making them as generic as they are in >Tastrade, where they refer to the methods as _SCREEN.ActiveForm.Method, requires all your forms to be based on a class which has >all these methods. Maybe that's not such a bad thing, but I'm not sure it's always desirable. I still think that if someone is >stuck modifying an app based on wizard code or something else inadequate, and doesn't have much time to start over, he'll be glad >to have a group of nav button container classes having the necessary nav methods which can drop into any ordinary form, possibly >replacing txtbtns. It's easy to fall into the trap of making quick fixes and never getting around to building things up right. >But it can be very hard to fit a good framework onto an old application.
Bret,

You'll get no argument from me about patching an exiting application.

However, if you are starting on a new application then there are some design considerations that you should think about. Some of them were mentioned in this thread. others were not. For example your issue about the form's needing to have those methods, well that is called a contract between the objects. In a good framework there are contracts and if you violate those contracts then the framework doesn't function correctly.

In my framework the code in the buttons looks like this;

THIS.Parent.oCreator.oForm.GoNext()

This requries that a few contracts have been met. 1) the button is sitting in a container that has an oCreator property, 2) oCreator points to the current application object, 3) the application object has an oForm property, 4) the oForm property points to the currently active form, and 4) the active form has a GoNext method. The fact that these contracts exist is not poor design at all. It is also a fact that my button classes may not work in your forms.