Alan,

>Good point. I'll have to review my toolbar classes.

As far as all of your positioning problems go, I think you are just dealing with the toolbar wanting to do it's own thing about it's sizing and object positioning based on it's set of rules.

I can select a separator on the property sheet and then mousedown on the grip and drag it to a new location. You can also move it with the arrow keys but that leaves grip droppings on the screen. Minimize and restore the class designer to clean up the design surface. But I don't have a problem dragging an inherited button to a new position, close the designer and reopen it the button is in it's moved location. My test toolbar classes are one dimensional (ie all buttons horizontal). But separators seem to have a mind of their own when you are trying to insert them "inside" what you are inheriting from the parent class.

I think to keep your sanity you'll have to go back and fix the separation in the parent class and only add new buttons/separators in the subclass. You can maybe use some creative RemoveObject() calls but remember the toolbar might end up resizing itself according to it's own whims. *g*

FWIW I don't put toolbars in my apps. IMO in a database app they are a waste of screen realestate. A toolbar with one 24x24 pixel button consumes 30x1920 pixels on my screen when it's top docked, and undocked toolbars have to be constantly moved around. Toolbars require much more mouse motion than having the buttons right on the form. Form buttons also avoid problems caused by the buttons not getting focus.