• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            公告

            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            統計

            • 隨筆 - 9
            • 文章 - 13
            • 評論 - 3
            • 引用 - 0

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            Getting an (ATL) ActiveX control to print from Office Applications
            13 votes for this article.
            Popularity: 4.73. Rating: 4.25 out of 5.

            Introduction

            Seeing as this is my first ever post to CodeProject, let me do a quick introduction as to who I am and what I do. I have been working in one form of C and C++ or another for as long as I can remember (among the other myriad of languages that I've run into). Nowadays, most of my development is focused on Microsoft Windows platforms, and is done in VC6, VC2002.NET. I am heavily entrenched in BI (Business Intelligence) development, and in my spare time develop little ActiveX controls and games etc...

            The plot

            Having learnt COM a while ago, I made the obvious progression to ATL to ease the development of boilerplate code, and to leverage off Microsoft's template library. As my experience grew, I ventured into creating ActiveX controls using the ATL framework ... and life was good. I could spew out a fairly useful (albeit not overly complex) control within a short period of time. Recently, I was asked to create a KPI (Key Performance Indicator) control that could be embedded in a web page and an Excel document. Obviously based on my experience (which was obviously not vast) I thought that this would be no problem and off I went, creating code that would meet the functional spec (we all work to these don't we :)).

            A couple of days later the control was finished and the final tests were being run when someone asked me to print a hardcopy of an example spreadsheet with the embedded control. This is where my nightmares began. Not only did my control not print, but there was no clear indication as to why it didn't print. And so my exploration into this apparent mystery began.

            Have you ever tried to include 3rd party ActiveX controls into an Office document? They sure seem to work fine, but most (apart from the Microsoft controls) don't seem to render themselves when you request a Print Preview or a simple Print of the worksheet or document. So, if any of you have ever had this problem, or have never dabbled with this, but think that you may be heading this way, take note of this, cos it might save you hours of frustration and frantic searching on MSDN and Google.

            So what now?

            The first thing one needs to realize is that even though we have been blessed with Office 2000 and Office XP, the printing architecture still uses the old Windows-format metafile for its printing operations. This metafile format was used in 16-bit Windows-based applications (thinks back to Win3.1). Now, this becomes a major problem for ActiveX developers who wish their controls to be printable from within Office applications, because this old metafile format only supported a limited set of GDI functionality. The list of supported GDI functions can be found here.

            Now that you are armed with your limited function set, you cringe with the realization that you can no longer create memory DC's, you can no longer use your lovely DrawText() functions and you can definitely no longer call GetTextExtentPoint32() function. However, those realizations only hold true for the instance of when your control is being rendered to an old format metafile. So how do we empower our control to know that its being rendered to an old format metafile? Simple, we use the GetObjectType() function and check if the result is equal to OBJ_METADC (old metafile format):

            HRESULT Cxxxxx::OnDraw(ATL_DRAWINFO& di)
            {
                HDC hdc = di.hdcDraw;
                bool bMetaFile = false;
            
                //// lets check if we're drawing to an old// metafile format.. (like Office printing)//if ( GetObjectType(hdc) == OBJ_METADC )
                    bOldMetaFile = true;
            
                //// the rest of your code...//
            }

            For interest, the opposite of OBJ_METADC is OBJ_ENHMETADC (refer to this MSDN document).

            Now that we know if we're drawing to an old metafile format or not, we can write adaptive code to cater for each instance or we can just write all our drawing logic using the limited set of functionality that is supported by the old metafile DC.

            What about fonts and text extents?

            As any ATL ActiveX developer knows, using fonts in AX controls provides for limited amount of fun. The typical piece of code would probably look something like this:

            																//
            																// ... some code
            																//
                CComQIPtr<IFont, &IID_IFont> pFont(m_pFont);
                TEXTMETRICOLE tm;if ( pFont != NULL )
                {
                    pFont->get_hFont(&newFont);
                    pFont->AddRefHfont(newFont);
                    pFont->QueryTextMetrics(&tm);
                    oldFont = (HFONT) SelectObject(dc, newFont);
                }

            The Bolded lines of code are ones that I didn't use regularly, due to the fact that I didn't really need to know about the breakdown of my font's details because I had access to GetTextExtentPoint32() function. Unfortunately, in this scenario, we don't have access to that function to determine how wide (in pixels) our text is going to be. But there is another way to calculate this fairly accurately, as is demonstrated in the code below:

            																//
            																// assume that we have called QueryTextMetrics() and
            																// have a filled TEXTMETRICOLE structure called tm
            																//
            CComBSTR strText(_T("Hello, world"));
            SIZE sz;
            
            sz.cx = strText.Length() * tm.tmAveCharWidth;
            sz.cy = tm.tmHeight;

            Having said this, there are many other functions that I use a lot that I can't use if I want my ActiveX control to be printable by Office, but as with GetTextExtentPoint32() and its respective replacement, there is always a way to replace these functions using Old-Metafile-Safe-Drawing-Code (OMSDC). *maybe that acronym will catch on*

            Conclusion

            When creating an ActiveX control that you know will be used inside Office applications, and will most probably be printed, remember to stick to these guidelines when developing your drawing logic. I was fairly shocked by how little information was available in the MSDN and online in general, while I was searching for information on how to enable my ActiveX control to print from within an Office application. There are hundreds of documents on ActiveX controls being printed from within Internet Explorer, but none address this particular issue. Perhaps I was looking in the wrong places. Hopefully this article will help one or more of you one day ;)

            Acknowledgment

            Many thanks to Igor Tandetnik for pointing me in the right direction on this.

            About Peter Mares

            posted on 2006-11-07 17:38 blues 閱讀(526) 評論(0)  編輯 收藏 引用

            国产精品久久网| 亚洲精品乱码久久久久久中文字幕 | 亚洲人AV永久一区二区三区久久| 久久国产免费直播| 久久午夜无码鲁丝片秋霞| 亚洲女久久久噜噜噜熟女| 欧美久久精品一级c片片| 人妻无码精品久久亚瑟影视 | 国产激情久久久久影院| 亚洲精品国精品久久99热| 久久亚洲精品人成综合网| 久久久久一本毛久久久| 国内精品久久久人妻中文字幕| 久久久久亚洲av毛片大| 99久久er这里只有精品18| 亚洲午夜久久久| 国产精品一区二区久久精品无码 | 欧美激情精品久久久久久久九九九 | 久久久久久久久66精品片| 狠狠狠色丁香婷婷综合久久五月| 久久这里的只有是精品23| 国产精品激情综合久久| 国产91久久精品一区二区| 精品久久久久久国产| 久久婷婷色综合一区二区| 国产免费福利体检区久久| 99久久er这里只有精品18| 久久香蕉超碰97国产精品| 少妇人妻综合久久中文字幕| 久久久久一本毛久久久| 久久精品亚洲欧美日韩久久| 久久婷婷久久一区二区三区| 久久精品一本到99热免费| 久久A级毛片免费观看| 精品蜜臀久久久久99网站| 国产69精品久久久久9999APGF| 亚洲国产视频久久| 久久精品视频一| 色婷婷综合久久久久中文| 久久ww精品w免费人成| 久久久国产精品网站|