Add Clipboard Copy Functionality Easily with Metafiles






4.35/5 (13 votes)
Nov 24, 2005
4 min read

89744

829
An article on how to implement clipboard copy with metafiles
Contents
- Introduction
- Background
- Using the Code
- The Demo Program
- Points of Interest
- Conclusion
- Bibliography
- History
Introduction
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.
Background
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
.
Using the Code
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); // device context for painting
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
{
/*
* The metafile is deleted only
* when it has not been set in
* the clipboard.
*/
::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 Program
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.
Points of interest
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) )
{
// Create a second device context that
// points to the screen, in order to make
// functions like GetTextExtent work correctly
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;
}
Conclusion
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.
Bibliography
- Charles Petzold, Programming Windows, Fifth Edition - Microsoft Press, 1999
- Jeff Prosise, Programming Windows with MFC, Second Edition - Microsoft Press, 1999
- George Shepherd, Scot Wingo, MFC Internals - Addison Wesley, 1996
History
- 12-03-2005
- Added mention of the potential attribute DC problem reported by Peter Boulton
- 11-23-2005
- Original article
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.