Re: MFC: A subclass of a subclass of CDialog
Zapanaz schrieb:
I am creating multiple CDialog's and have custom painting that they
all do the same ... so, I am trying to create a class SubDlgBase which
has all the painting in it, then descend my SubDlg's from it.
No problem, I've done it multiple times.
I can't figure out how to create a visual component which is a
subclass of my own class, which is descended from CDialog.
That part is easy. Derive your dialogs from CDialog, let the wizard generate the
code, and then change the base class from CDialog to SubDlgBase. The trick is to
do this in all three(?) places, not only in the class declaration. The best is
you use search&replace on both the cpp and h file to do this. If I remember, the
base class name appears
* In the class declaration (class MySub1 : public CDialog)
* At the top of the class implementation in
IMPLEMENT_DYNAMIC(MySub1, CDialog)
* In the message map definition BEGIN_MESSAGE_MAP(MySub1, CDialog).
(tis is ftom my memory, forgive me if I got a name wrong)
See below for more comments
On Sun, 30 Dec 2007 23:17:39 -0600, "Doug Harrison [MVP]"
<dsh@mvps.org> wrote:
I renamed AppDialog1 to
AppDialog1.1 so I could work on it without messing up AppDialog1,
which works ... is an x.x naming convention a problem?
Yes, it's a problem. The dot is not a legal character for identifiers. The
only non-alphanumeric character you can use is the underscore. Just don't
begin identifiers with the underscore or use two of them in a row, because
such names are reserved.
I believe you've described the hierarchy:
CDialog <- SubDlgBase <- SubDlg1, SubDlg2, SubDlg3, ...
Like CDialog, the SubDlgBase class will not have an IDD enum member, but
the derived classes, SubDlg1, SubDlg2, etc, will, because they are
associated with dialog resources. Your SubDlgBase class should define a
ctor SubDlgBase(UINT id, CWnd* parent) that chains to the corresponding
CDialog ctor. You should be able to set this up in ClassWizard such that
SubDlgBase and the derived subdialogs are all available there. It's been a
long time since I did this, but IIRC, after creating SubDlgBase, you will
delete its IDD member and the dialog template ClassWizard created for it.
Then you will modify its ctor as I described earlier. What you are trying
to do is definitely possible, and it works with full ClassWizard support
for the created classes. At least that was the case in VC6, which is where
I did it.
P.S. The best group for this question would have been
microsoft.public.vc.mfc.
Thanks very much for the help.
It turns out the dot in the class name was the source of most of my
problems. I guess I've just never run into that before, never tried
to use a dot in a class name before ...
***
It's still kind of a hassle, but nothing I can't work around (well,
hopefully). The visual builder only allows you to subclass from an
MFC class, or choose an existing class from among classes you have
already defined by subclassing them from MFC classes (MSVC++ 6). So
the only way I can see to do it is
1. Create SubDlgBase from CDialog in the visual builder
ok
2. Create SubDlg1 from CDialog
ok
3. Manually edit SubDlg1 to descend from SubDlgBase
Yes, but replace all three or forut ocurences of CDialog with SubDlgBase, not
only the one in the header file.
4. Copy all the visual components (text boxes, buttons, etc) from the
already-existing visual classes into the new classes
> 5. Copy all the existing code likewise
When you already have the code in some classes, why create new classes and cop
the old code to it?
6. Cross fingers
You forgot to manipulate the constructor of SubDlgBase as Doug told you.
Carefully read his reply again.
But I can't just modify my existing SubDlg1 to subclass from
SubDlgBase, because the visual class is descended from CDialog, so
even if I change SubDlg1 in my code to descend from SubDlgBase, when I
build and execute it still behaves as a subclass of CDialog, not
SubDlgBase.
That is not true. Virtual functions work perfectly fine through many levels of
hierarchy.
However, most message handlers in MFC are not implemented with virtual
functions, but by "manual" message lookup with the help of the message mapping
macros. I guess you forgot to copy the message map entries to the correct class.
When you forget that, the code compiles but the hanlders are not called.
In addition, when you implement OnPaint in the base dialog, the derived dialogs
can not have a OnPaint as well, you can only have one OnPaint. If the derived
dialogs should do some custom painting, then you would need to add some OnDraw
virtual function in your base and override it in the deriveed. The base OnPaint
would then call the overloaded OnDraw at some time during its OnPaint handling.
Oh, crap.
No, it is easy. Just replace the base class name in all places, and update the
base constructor.
Now that I actually type this out ... this isn't going to work.
Whatever I do, in the visual builder, I will have the choice to either
descend from an MFC class, or instantiate one of my own classes. And
all of those classes are likewise descended one step from MFC classes.
Yes, but to change this after class creation is easy, see above.
I mean in the Class Wizard, you have the choice of:
- Create a New Class ... which lets you subclass from an existing
class ... but which only gives you MFC classes as options
- Select an existing class ... which lets you choose from your own
classes, but only to instantiate them, not to subclass them
argh. Maybe, tomorrow, if like I say I manually edit SubDlg1 to
descend from SubDlgBase, instead of CDialog as it is now, it will be
fooled into letting me instantiate it. (Currently I do have the
choice to instantiate a SubDlg1, but it's descended from CDialog
instead of SubDlgBase). But I think I am going to still have the same
problem ... since the visual component was originally descended from
CDialog, I think it is going to do the same thing and continue
behaving as a subclass of CDialog, not SubDlgBase.
Well really in retrospect, I have spent a lot more time working around
the time-saving visual builder than I would have I had done this all
in code from the start.
Well, it is harder to setup the message mapping right in the first try, so I
still prefer the class wizard thing. In addition, even after you changed the
base, you can still add new metthods using class wizard.
Norbert