Hmmm sounds interesting and a little bit like the second situation I described. I am assuming that the toolbars still act like toolbars when created the way you are doing?

Just as a comparison, I might have been tempted to create a master tool bar that contains all the buttons properly spaced and then, in the init, remove the buttons and spacers that are not needed depending on the user and other criteria. This would make it Object Oriented and totally independent so you need only one class and eliminate maintenace problems required by having 8-10 toolbars per application. Did you look at this approach? Would it work in this type of situation?

>Bruce,
>
>We have a modular application, e.g. Sales, Purchases, etc... It has been
>decided, after consultation, that users DO NOT want menus. Our application
>has no menus whatsoever. Users switch from one module to another through
>the main Toolbar, click on Sales to get Sales, click on Purchases to
>get Purchases, etc.... (Incidentally Sales and Purchases are here purely
>as examples, those are not the real names).
>
>Users are expecting the icons in specific places on the toolbar, yet
>not all of the icons are available to all users depending on what rights
>the users have, etc... Additionally, users expect specific spacing between
>categories of button. All of this to create a toolbar system where
>users click on buttons "almost without looking". The result is that for
>most applications we have there can be up to 8 to 10 toolbars.
>
>That's the reason for the multitude of toolbars. It has worked and the
>users love it.
>
>Regards,
>Michel.
>