PMFJI *s* Hi, Ed.

John: this is _exactly_ the solution I came up with, so, well, it could hardly be cheezy *rbg*. Anyway, I think it works fine, even on toolbars that move--if it makes some sense that the controls be grouped. But, if it didn't make sense, you probably wouldn't care if they split up, huh? And, you're right, it's straightforward.

Now, of course, theoretically, you could move your container's controls around depending on the toolbar's docked status...

>Ed:
>
>>>
>>>No. A toolbar made this way will have to be engineered in the classlib to be either one or the other. This works best for a main toolbar where you don't intend to allow the user to move or close it.
>>
>>I allow to move (no close) :).
>
>Jeez!!! Alright already!! Seriously, my Tip is intended for master toolbars that are not going to be moved or closed. Having everything wrapped into a container within the toolbar is far, far easier to get fancy with buttons, comboboxes, bitmaps, et al.