Peter,

>Thanks much for the extensive outlay. I will look into it seriously.

I think this has been a useful exchange of information. Thanks to you too.

>*** When the mouse leaves, but the control is active, don't let it return to the flat state.

Personally I think hot tracking is only somthing I'd use if and only if I was creating a toolbar that I wanted to use have the look and feel of other Windows apps current "gee whiz isn't this cool" toolbars. To a large degree this is pretty meaningless eye candy IMHO it has nothing to do with functionality. I certainly wouldn't be putting these "frills" on every control on every form, it's a waste of CPU cycles and enduser time IMHO. I think you and I have a different frame of mind when it comes to GUIs.

I'll admit though that I don't develop "general populace" sorts of applications, my client base was small and focused while I was a consultant and now my development is for our internal application. I'm at a point that I do very little GUI development now. I work more with bizobjects, data and the backend nowadays.

>David, my main question would be, how would this compare to your way of working. I guess there is not much difference, but I am not sure yet.

Since the current state of this topic has gone to GUI elements, I go back to something I've already said, I'd delegate all of this activity to methods the form class itself. All of these things you've been talking about fit a Decorator Pattern. The form can decorate itself with each of these visual features and your lowest level control classes can simply delegate to the form instead of the UDFs in the PRG based procedure library you are now using.

>PS: I don't have navbuttons on the toolbar, but on the form (they are not "general" enough :))

The biggest problem I have with nav buttons on a toolbar was that it was too complex to make them DS aware. A container of buttons on the form itself is much less complex, and therefore was the route I chose to go.