The above suggests a new design, where the "Frame" and "FrameMini" classes simply instantiate "wxFrame" or "wxMiniFrame" directly. I don't see any immediate problems with this, and it's simpler, which is only good.The immediate problem is that wxFrame seems to require a subclass to handle event processing correctly. Consequently, there needs to be a subclass.
Is the Backing class changeable for you?Yes.
Maybe cou could split it up into a functionality part which does not inherit from wxFrame and a (possibly templated) combiner class which inherits from Backing and wxFrame and another combiner class which inherits from Backing and wxMiniFrame. Then let Backingframe inherit from the first combiner class and BackingframeMini inherit from the second.Actually, I had tried something similar to (but not quite the same as) this, and IIRC, it was similar to how it was originally implemented. Unfortunately, the amount of functionality that must be delegated by method stubs out to the subclasses makes it inelegant in the extreme. It is particularly irksome, since many of the method calls are exactly the same between wxFrame and wxMiniFrame--so they have to be delegated out to two different methods which make exactly the same calls.
Or leave the combiner class out and have BackingFrame inherit Backing and wxFrame and BackingframeMini inherit Backing and wxMiniFrame.This is actually essentially what I'm implementing now. Frame and FrameMini instantiate BackingFrame and BackingFrameMini. The common functionality, I'm pretty sure, lies entirely within wxFrame, so FrameBase can store it as a pointer to wxFrame. BUT, there's no need for a common backing class anymore, which fixed the virtual inheritance problem:
FrameBase | |
| | v
____|____ | wxMiniFrame
| | | |
| | | |
v v | |
Frame FrameMini | |
It has the disadvantage of BackingFrame and BackingFrameMini not sharing a common parent (one is kindof like an "uncle" :-)), but wrapper classes do end up being kinda messy . . .