-
March 17th, 2004, 04:37 PM
#1
overriding mfc inheritance
Here is the MFC class hierachy:
CObject
|
CCmdTarget
|
CWnd
|
CDialog
|
CPropertyPage
Will I be able to do something like this ? :
CObject
|
CCmdTarget
|
CWnd
|
SDialog
|
CPropertyPage
My SDialog derives from CDialog.
My SDialog has functionality that I want to be able to use in my class (CMyPropertyPage) that I will derive from CPropertyPage....
One obvious approach is to use multiple inheritance:
CMyPropertyPage : public CPropertyPage, public SDialog
{
}
Thanks,
MD
-
March 17th, 2004, 05:47 PM
#2
Re: overriding mfc inheritance
Multiple inheritance is strongly discouraged with MFC - especially when deriving from two classes which are both derived from CWnd as in your case - this won't work anyway.
You should probably implement the functionality you need in a class derived from CPropertyPage. If you absolutely need to share some part of the implementation for both CDialog- and CPropertyPage-derived classes, you could still consider creating a mix-in class with that behaviour (however, that class must nor be derived from CWnd or any other MFC class like CObject). You could then use multiple inheritance, deriving CYourDialog from CDialog and the mix-in class, and CYourPropertyPage from CPropertyPage and the mix-in class.
-
March 17th, 2004, 08:47 PM
#3
Hi gstercken,
I am very curious to find out what's a mixin. Would you roughly explain what is it and what problem it solve. I couldn't find anything good from google search, probably I am not using the correct keyword.
Thanks in advance.
-
March 17th, 2004, 11:30 PM
#4
What GStercken calls a mix-in class might also be called a helper class. Try to put whatever functionality you have in SDialog that would also be helpful in your CPropertyPage derived class.
Even if some of that functionality is dependent on the HWND that SDialog wraps, you can still have a helper class that is NOT derived from CWnd, the base wrapper class for HWND.
Split out the needed functionality in SDialog like so...
BOOL CHelper:oSomethingTrick(HWND hwnd)
{
//Do all this neat stuff
return TRUE;
}
When SDialog needs this functionality, it can call the CHelper object (which could be a member of SDialog) and passes in its HWND.
ASSERT(m_Helper.DoSomethingTrick(m_hWnd));
Or you could use multiple inheritance so that SDialog is derived from CHelper.
As gstercken said, just so long as both classes are not derived from CWnd.
Steve
-
March 18th, 2004, 04:21 AM
#5
Re: Re: overriding mfc inheritance
Originally posted by gstercken
Multiple inheritance is strongly discouraged with MFC - especially when deriving from two classes which are both derived from CWnd as in your case - this won't work anyway.
Just out of curiosity...do you happen to know whether this includes virtual derivation as well?
-
March 18th, 2004, 05:37 PM
#6
Re: Re: Re: overriding mfc inheritance
Originally posted by Andreas Masur
Just out of curiosity...do you happen to know whether this includes virtual derivation as well?
Yes, even virtual derivation will not solve all the problems which arise when multiply deriving from certain MFC classes. From MSDN, TN016:
You may ask, "If you inherit CObject virtually, won't all of the ambiguity problems go away?".
[...]
The real answer is no, virtual inheritance will not solve the ambiguity problems illustrated above. For example: the Dump virtual member function is still ambiguous (since CFrameWnd and CObList implement it differently).
-
March 24th, 2004, 05:01 PM
#7
Thanks very much for your replies. Clarified many points...
The approach I am trying to resolve my problem is:
CObject
|
CCmdTarget
|
CWnd
|
CDialog
|
CPropertyPage
|
SPropertyPage
|
SDialog
All my application dialogs/property pages now derive from SDialog.
The drawback is that the dialogs that do not require the property page functionality will inherit it -- this was something I can give up.
I need this approach as at the application frame level, I have to invoke functions within the child dialogs, and at run time its sufficient enough to know that I have an SDialog pointer and
call appropriate function using a typecast.
Something like this:
CWnd *pChild = GetChildWindow();
if (pChild)
{
((SDialog *)pChild)->SetActiveDate();
}
Because all my dialogs inherit from SDialog....I can easily do this, SetActiveDate() is declared virtual in SDialog.
The one thing I was not sure about was:
The CDialog constructor required a pointer to the parent:
CDialog( UINT nIDTemplate, CWnd* pParentWnd = NULL );
If I had to pass the value of pParentWnd up the hierarchy, how would I do it as the CPropertyPage/SPropertyPage constructor did not require it. So far I have not come across a reason to do this.
Thanks,
MD
-
March 24th, 2004, 05:41 PM
#8
Re: Re: Re: Re: overriding mfc inheritance
Originally posted by gstercken
Yes, even virtual derivation will not solve all the problems which arise when multiply deriving from certain MFC classes.
Sorry for the late reply...but thank you very much for the information...
-
March 25th, 2004, 12:46 AM
#9
CDialog stores the parent wnd pointer in m_pParentWnd. If it is NULL, the default argument, then CDialog simply calls AfxGetMainWnd() to get a pointer, so you could do the same.
Also, unless the derived classes implement their own version of SetActiveDate(), you don't need to make it virtual in the SDialog class.
Steve
-
March 25th, 2004, 04:21 PM
#10
Thanks very much for the info Steve,
-MD
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|