>>>Dang, I just wrote another book. Well, it's the core of our frameworks. Care to comment?
>>Bret,
>>
>>Only a brief comment from me .
>>
>>First the reason to define the buttons separately is that they can then be combined into different containers in different configurations without need to modify any code. Now I agree that the buttons should not have code in them that really does anythijng, they should be calling methods of the form and the form shouldb e doing the stuff. This approach lets you decide to use buttons in the form or buttons in a toolbar or hot keys in a menu or buttons on the telephone or light switches on the wall. You don't need to make these decisions right away and you can easily change them later. This approach is called delegation, as the buttons delegate responsibility for the behavior to the form.
>>
>>Why define the buttons external and separately, well because you can never remove anything form a parentclass in a subclass, therefore if you want to have multiple configrations of buttons you need to have multiple container classes that have those configurations. These containers should not superclass - subclass related but rather they should all be sibling classes at the same level in the hierarchy. By having a cmdTop, cmdNext, cmdPrior,cmdBottom,cmdEdit, cmdAdd, cmdSave,cdmRevert,cmdExit, etc. buttons all fully functional, you can then create seveal containers each having a diffeent combination of these button classes in them. The code for the button classes is not duplicated, it appears only once in the button class definition. If you decide someday that you want a cmdEditFlashing that makes the whole screen flash wduring the eidt, you can subclass the cmdEdit button and modify its behavior. You cannot do this if the buttons are defined as part of the container (like in
>>Wizstyle.vcx).
>>
>>Also modifying behavior in the object is much easier, if you want to add a message box to the cmdDelete button in one fomr you can just edit the click event for that button in that form and;
>>
>> * cmdDelete Click
>> IF Messagebox(...) = IDYES
>> cmdDelete::Click()
>> ENDIF
>>
>>instead of;
>>
>> *cmddelete click
>> IF messagebox ...
>> txtBtns.cmdDelete::Click()
>> ENDIF
>>
>>You see with the early composition (meaning before the code is in the button classes, you have to idnetify the button as a member of the container. But with late composition (the code exists in a button class before it was added to teh container) you only need to identify the button class.
>>
>>Hope this give you some ideas.
>
>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.

Your suggestion is very helpful to me. I appreciate a lot. Thx