Add Clipboard Copy Functionality Easily with Metafiles

• Download demo project - 44.3 KB

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.