Best design for Windows forms that will share common functionality

Question

In the past, I have used inheritance to allow the extension of Windows forms in my application. If all of my forms would have common controls, artwork, and functionality, I would create a base form implementing the common controls and functionality and then allow other controls to inherit from that base form. However, I have run into a few problems with that design.

1. Controls can only be in one container at a time, so any static controls you have will be tricky. For example: Suppose you had a base form called BaseForm which contained a TreeView which you make protected and static so that all of the other (derived) instances of this class can modify and display the same TreeView. This would not work for multiple classes inheriting from BaseForm, because that TreeView can only be in one container at a time. It would likely be on the last form initialized. Though every instance could edit the control, it would only display in one at a given time. Of course, there are work-arounds, but they are all ugly. (This seems to be a really bad design to me. Why can't multiple containers store pointers to the same object? Anyhow, it is what it is.)

2. State between forms, that is, button states, label text, etc., I have to use global variables for and reset the states on Load.

3. This isn't really supported by Visual Studio's designer very well.

Is there a better, yet still easily maintainable design to use? Or is form inheritance still the best approach?

Update I went from looking at MVC to MVP to the Observer Pattern to the Event Pattern. Here is what I am thinking for the moment, please critique:

My BaseForm class will only contain the controls, and events connected to those controls. All events that need any sort of logic to handle them will pass immediately to the BaseFormPresenter class. This class will handle the data from the UI, perform any logical operations, and then update the BaseFormModel. The Model will expose events, which will fire upon state changes, to the Presenter class, which it will subscribe (or observe) to. When the Presenter receives the event notification, it will perform any logic, and then the Presenter will modify the View accordingly.

There will only be one of each Model class in memory, but there could potentially be many instances of the BaseForm and therefore the BaseFormPresenter. This would solve my problem of synchronizing each instance of the BaseForm to the same data model.

Questions:

Which layer should store stuff like, the last pressed button, so that I can keep it highlighted for the user (like in a CSS menu) between forms?

Please criticize this design. Thanks for your help!