Contents
While I was reading Charles Petzold's Programming Windows book, more specifically the chapter on metafiles, I was wondering what could be the potential usages of such a feature in a real world application. The chapter describes in length what metafiles do and how they work, but little is said about what you can do with them or why you should use them. I think that I found a worthwhile application for metafiles and I am going to share it with you. This article has no claims of inventing a revolutionary technique as it is ridiculously simple, but at the same time, it does not seem to be widely known. This technique is for sharing data among different applications, as for sharing the data among the same application, private data formats might be more appropriate. In this article, I will give a brief overview of what metafiles are, and then I will present the technique.
There are two types of metafiles: the original ones that have been around since Windows 1.0, and the enhanced metafiles. The difference between them is very small. The enhanced metafiles have a slightly more detailed header which makes them more self contained. There is no good reason to use the original metafiles unless you have to keep compatibility with an old Win16 application. If it is not the case, then you should stick with the enhanced metafiles. Metafiles are GDI objects that once opened will return a device context. Metafiles store all the GDI function calls performed with their DC and then allow the user to perform a playback of the stored GDI calls. They are one of the standard data formats that the clipboard accepts. MFC encapsulates metafiles functionality in the class CMetaFileDC
which derives from the class CDC
.
The technique consists of putting your drawing code in a function that takes a device context object pointer as an input parameter:
void Draw(CDC *pdc);
This function can be called from your WM_PAINT
handler:
void CChildView::OnPaint()
{
CPaintDC dc(this);
Draw(&dc);
}
Now, your new copy handler will look like this:
void CChildView::OnEditCopy()
{
CMetaFileDC mfdc;
if( mfdc.CreateEnhanced(NULL,NULL,NULL,NULL) )
{
Draw(&mfdc);
HENHMETAFILE hmf;
if( (hmf = mfdc.CloseEnhanced()) )
{
if( OpenClipboard() )
{
EmptyClipboard();
SetClipboardData(CF_ENHMETAFILE, hmf);
CloseClipboard();
}
else
{
::DeleteEnhMetaFile(hmf);
}
}
}
}
This is all that your program needs, to be able to copy the client area content and paste it in any application supporting metafiles.
The demo is just a simple MFC AppWizard
generated SDI application where a bogus drawing function has been added to prove the concept. Then, the copy handler has been added to the CChildView
class.
You can easily adapt this code to a MFC View/Document program or a Win32 API program. Also, an astute reader pointed out that if your OnDraw()
function calls attribute GDI functions such as GetTextExtent()
, you must first manually set the metafile h_hAttribDC
. You can either do that with a CClientDC
or with an information context like this:
CMetaFileDC mfdc;
if( mfdc.CreateEnhanced(NULL,NULL,NULL,NULL) )
{
CDC cdc;
VERIFY(cdc.CreateIC(__TEXT("DISPLAY"),NULL,NULL,NULL));
mfdc.SetAttribDC(cdc.m_hAttribDC);
Draw(&mfdc);
...
}
You cannot call SetAttribDC()
with mfdc.m_hDC
because the CMetafileDC
version of this function forbids you to set m_hAttribDC
to m_hDC
but this is wrong! It should work because the first parameter of CreateEnhanced
is:
pDCRef
- Identifies a reference device for the enhanced metafile
When it is NULL
, the reference device will be the display. The reason why MFC ignores pDCRef
and sets m_hAttribDC
to NULL
is probably because CMetafileDC
also supports the old Windows 1.0 metafile format and these metafiles have no notion of reference devices. As a side note, I just do not like the attribute DC notion of MFC DC classes because most of the time m_hDC
is the same as m_hAttribDC
and the presence of m_hAttribDC
just adds a superfluous overhead all over the CDC code. The only exception where m_hAttribDC
is actually useful is in CPreviewDC
used in the MFC print preview feature. Here is an example of this from the MFC source code:
CPoint CDC::MoveTo(int x, int y)
{
ASSERT(m_hDC != NULL);
CPoint point;
if (m_hDC != m_hAttribDC)
VERIFY(::MoveToEx(m_hDC, x, y, &point));
if (m_hAttribDC != NULL)
VERIFY(::MoveToEx(m_hAttribDC, x, y, &point));
return point;
}
That is it! I hope you enjoyed this article, and if you did and found it useful, please take a few seconds to rank it. You can do so right at the bottom of the article.
- 12-03-2005
- Added mention of the potential attribute DC problem reported by Peter Boulton
- 11-23-2005
License
This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.
A list of licenses authors might use can be found here.