MFC 8: I'm Not Dead Yet

What's New for MFC in Visual Studio 2005
http://www.codeguru.com/Cpp/misc/misc/mfchelp/article.php/c10147/
Rating: 
 Victor Volkman (view profile)
July 11, 2005  
Rather like the plaintive peasant in Monty Python & The Holy Grail, MFC 
8 begs you to consider it viable for another development cycle. We do ha
ve comforting reassurances from Microsoft's own Steve Teixeira in an ext
remely brief whitepaper "MFC: Visual Studio 2005 and Beyond."
http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx 
The subtext seems to be that MFC has been revved to meet the bare requir
ements feature-set of Visual Studio 2005 for now, but will be retrofitte
d in the future to meet the needs of Longhorn:
"After the release of Windows Longhorn, Microsoft intends to add MFC sup
port for key Longhorn APIs and features. Microsoft also intends to suppo
rt the Avalon user interface framework in MFC, providing MFC developers 
with a bridge to the future of platform user interface design. In essenc
e, as the platform evolves, developers can look forward to seeing MFC up
dated to leverage the latest managed and native APIs and frameworks."
Now with Windows Forms!
The biggest single upgrade to MFC is the addition of Windows Forms suppo
rt Windows Forms support. By using the MFC Windows Forms support classes
, you can host Windows Forms controls within your MFC applications as Ac
tiveX controls within MFC dialog boxes (CWinFormsControl) or views (CWin
FormsView). In addition, Windows Forms forms can be hosted as MFC dialog
 boxes (see afxwinforms.h).
Header Annotations
Steve told me that an exhaustive list of MFC fixes and improvements was 
not available at the time of this writing, so I took it upon myself to d
iff some of the key header files myself and report to you.
I figured on starting with the mother-of-all MFC headers, afxwin.h. One 
of the first things to notice is the use of the new "header annotations"
 that formalize what people used to only have available as wishful comme
nts when doing design-by-contract specifications: __in means an input pa
rameter, __out indicates an output parameter, and __inout means the valu
e is both read and written by the underlying function. To avoid the drea
ded buffer-overrun attack, the __bcount annotation puts a hard limit on 
access. When you enable Code Analysis in VS 2005, all these annotations 
are checked.
Other cool annotations you might want to use for your own code are: __ch
eckReturn, which forces the caller to check the return value; and __null
terminated, which means the buffer may only be accessed up to and includ
ing the first null (0) character.
Improving const-correctness is one of the nice cleanups added to this ve
rsion of MFC. For example, in CRgn the CombinRgn, CopyRgn, and EqualRgn 
methods finally have const applied correctly. Also, there are similar co
nst fixes to CDC drawing methods.
CDC World Transforms
The venerable CDC object gets some new functionality in mapping function
s:
// Graphics mode
int SetGraphicsMode(int iMode);
int GetGraphicsMode() const;
The only new mode is GM_ADVANCED, which allows the new transformation me
thods shown below to be incorporated into enhanced (in other words, Win3
2) metafiles. GM_ADVANCED mode also fixes a couple of longstanding bugs 
in world-to-device transformations: TrueType fonts can scale both width 
and height, rectangles now include the bottom-right coordinate, and arc 
control points always draw counterclockwise in the logical space. Though
 not guaranteed to reproduce exactly on Win98, MFC may still make a "bes
t effort" to render the transforms.
// World transform
BOOL SetWorldTransform(const XFORM* pXform);
BOOL ModifyWorldTransform(const XFORM* pXform,DWORD iMode);
BOOL GetWorldTransform(XFORM* pXform) const;
Anyone familiar with OpenGL will immediately recognize the value of thes
e transforms and their traditional role of rotating, translating ("movin
g"), and scaling graphics. In the case of the GDI, these are merely 2-D 
transforms.
CWnd and CWinApp Additional Flags and Funcs
The purpose is less apparent of the two new CWnd::m_nFlags values WF_NOW
IN32ISDIALOGMSG and WF_ISWINFORMSVIEWWND. The former seems to force GetN
extDlgTabItem to continue on where it might normally stop looking for ch
ild windows. The latter affects whether COccManager::IsDialogMessage del
egates to the Windows implementation as a last resort.
CWnd includes a new overload for special controls (WinForms) that requir
e more than just a CLSID to initialize by passing a reference to a CCont
rolCreationInfo object. To use this new overload, you must first call Af
xEnableControlContainer in your InitInstance function.
The new EnsureParentFrame() and EnsureTopLevelParent() methods replace t
he previous GetParentFrame() and GetTopLevelParent() methods at least fo
r internal use and feature heavily in wincore.cpp. These functions have 
the added benefit of throwing an exception rather than returning just gi
ving up and returning NULL.
SetOccDialogInfo method now has a companion GetOccDialogInfo.
The virtual Create method was stripped from several controls including C
Edit, CStatusBarCtrl, CListCtrl, CTreeCtrl, CToolbarCtrl, CReBarCtrl, an
d CRichEditCtrl, to achieve better binary compatibility (for example, CT
oolbarCtrl and CToolbar need to be compatible).
CWinApp has a new static method ShowAppMessageBox for message boxes whic
h can work when no CWinApp objects can be found. This works in conjuncti
on with another new static method is DoEnableModeless.
AFX.H Improvements
The new REPORT_EXCEPTION() macro provides a simple foolproof way of deco
ding a pException object and putting up an AfxMessageBox in DEBUG mode o
r a TRACE macro if in RELEASE mode. AFXIsValidAtom() provides validators
 for both atom handles and strings. AfxEnableMemoryLeakOverride() gives 
you precision control over whether the AfxEnableMemoryTracking() is allo
wed to prevail. Last, CArchive now includes << operator overrides for AT
L::CStringT family of strings.