We do something similar. We add a custom method (ToolBarClick()) to the base form for processing toolbar button clicks. The toolbar then simply calls the ToolBarClick() method of the ActiveForm, and passes a toolbar button ID (like TB_ADD, TB_DELETE, ...). The form has a case statement for each ID that it can process.

We actually go a little further and have an application manager object that coordinates all this stuff. If the form cannot handle the ID (its not in it's CASE statement), then it returns FALSE. The application manager then passes this off to other code that tries to process the ID. This allows us to have buttons up that are independent of the form, and not force the form to deal with them.


>1. A standard toolbar for the entire app for things like navigation, editing, adding, saving and reverting.
>2. Form specific toolbars based on individual forms needs.
>3. Custom methods in forms like AddRec, SaveRec, etc.
>4. The only code in toolbar.btn.click is to check if ActiveForm has a particular method and call it. This way the toolbar is generic to any form.
>5. I use a custom method in each form called IsEnabled that is used for >individual toolbar.btn.enabled values and menu pads SKIP FOR options.
>
>HTH
>
>>I just started incorporating toolbars into my application (retrofit) and I am unsure on the "best practice" or approach of doing this. Should there be one toolbar for each form? should there be one toolbar for many forms where the objects on the toolbar are changed according to the active form? Where should the code be placed...in the toolbar buttons events or in a custom form method? etc. Any basic guidance here on incorporating toolbars is greatly appreciated.
>>
>>Thanks,
>>John.