MFC does support multiple inheritance.
But its not designed in such a way.
Every(should be most) objects are derived from CObject, but none of them are virtual.
This makes that deriving from two MFC parent classes will result in two different root objects.
This is surely bad for the whole MFC design.
So one might say MFC doesn't support Multiple Inheritance in a Usable way.
Adding your own class(non MFC derived) should work.
One problem with MFC and multiple inheritance is that nearly all MFC classes are ultimately derived from CObject. If you then inherit from 2 MFC classes for a new class it gets 2 copies of CObject internally and which one existing code refers to is then ambiguous. This screws up things like MFC Serialization which rely on funtions inherited from CObject. The reasons why virtual inheritance was not used within the MFC Framework to prevent this being a problem are obscure. Someone with C++ guru status would probably be able to explain it.
I have a feeling that there are ways to make it work with a lot of effort becuase I remember seeing an article on CodeProject that claimed to have a solution. I didn't read it or save a link so you'll need to hunt for it yourself if you're interested.
In most cases multiple inheritance can be avoided anyway by making one of the bases a class member instead and exposing the parts of the interface you want by writing your own wrappers. Have a look at some of the tricks ATL uses aswell with template paremters used for base classes; an alternative powerful technique that can sometimes meet your requirements instead of using multiple inheritance.
Nothing is exactly what it seems but everything with seems can be unpicked.
Have a look at some of the tricks ATL uses aswell with template paremters used for base classes; an alternative powerful technique that can sometimes meet your requirements instead of using multiple inheritance.
That seems to say "use the ATL technique "instead of" multiple inheritance"
if ( !OpenClipboard() )
AfxMessageBox( "Cannot open the Clipboard" );
// Remove the current Clipboard contents
if( !EmptyClipboard() )
AfxMessageBox( "Cannot empty the Clipboard" );
// Get the currently selected data, hData handle to
// global memory of data
// For the appropriate data formats...
if ( ::SetClipboardData( CF_??, hData ) == NULL )
AfxMessageBox( "Unable to set Clipboard data" );
What shows in the tooltip is simply the current caption of your window. So you can use SetWindowText() to change it. Note, though, that this is not always advisable, especially if writing in MFC - the MFC framework handles the window title.
I am wondering what is the function of .suo file? If I want to share source codes with other people, for example, using CVS or something similar, does this file mandatory to check-in? Do other people need this file to make a same build and setup the same working environment as mine?
No, you don't need to share this file. The only files that you need to save into CVS are the source files (.cpp and .h), the solution file (.sln) and the project files (.vcproj, one for each project in your solution). This is for VS2005, for VC6 the project and 'solution' files are different (.dsw and .dsp) and for VS2003, I don't know