[MSDN文章]CHtmlCtrl 来实现在对话框中中链接效果

Code for this article: Jan00CQA.exe (248KB)
Paul DiLascia is the author of Windows ++: Writing Reusable Code in C++ (Addison-Wesley, 1992) and a freelance consultant and writer-at-large. He can be reached at askpd@pobox.com or http://pobox.com/~askpd.

Q I noticed that MFC 6.0 has a new CHtmlView that lets you view Web pages within a view. I would like to use CHtmlView in a dialog, but when I do, it crashes. Is there a corresponding CHtmlCtrl class like there is for CListView and CListCtrl? If not, how can I display HTML inside a control in my dialog?

Max Burton
San Diego

A First of all, that's not MFC 6.0—that's the Visual Studio® 6.0 version of MFC 4.2. For an explanation of this perplexing version number scheme, see my article, "Visual C++® 6.0 Brings Home a Full Bag of Tricks and Treats for MFC Developers," in the October 1998 issue of MSJ. As for your question: no, there's no CHtmlCtrl corresponding to CHtmlView, but—lucky you—it's not hard to write one.
What, after all, is the difference between a view and a control? Not much. Both are child windows; the only difference is how they're used. Controls are usually child windows in a dialog—though of course you can create a control as a child of any window you like—whereas views are special child windows designed to work in the MFC doc/view architecture. A view has a pointer to a document and it's designed to live inside a particular kind of window—namely, a frame (CFrameWnd).
As for the document, CView is written so that the document pointer, m_pDocument, can be NULL. Any time the view does something with the document, it encloses the code within

 if (m_pDocument!=NULL) { }

So a view doesn't really need a document. Nor does CHtmlView require one. You might think the document in CHtmlView is the HTML file, but in fact CHtmlView is implemented using IWebBrowser2, which has no knowledge of the MFC doc/view architecture.
So CHtmlView doesn't need a document. What about the frame? If you examine the code carefully, you'll discover that there are very few places where a view knows that it belongs to a frame. Most of the doc/view stuff is implemented in higher-level classes such as the frame itself and CDocTemplate, which glues the frame, document, and view together. The view doesn't know too much about what's going on, which shows the system is well-designed. Conceptually, the frame controls the view—not the other way around—so it would be a mistake if the view knew about its parent window. Nevertheless, a little spaghetti wiring always creeps in to any system (usually to fix bugs), and MFC is no exception.
There are two places where CView (and hence CHtmlView by inheritance) assumes it lives inside a frame. The first is CView::OnMouseActivate, the handler for WM_MOUSEACTIVATE. OnMouseActivate does a lot of mumbo-jumbo to make activation work properly when the user clicks the mouse on a view. The details aren't important; the important thing is that the view calls GetParentFrame to get its parent frame, and then CFrameWnd::GetActiveView to activate the active view—all of which assumes the view is a child window of a CFrameWnd.
The other place the view knows it lives in a frame is in CView::OnDestroy.

 void CView::OnDestroy()
 {
   CFrameWnd* pFrame = GetParentFrame();
   if (pFrame != NULL && pFrame->GetActiveView() == 
       this)
     // deactivate during death
     pFrame->SetActiveView(NULL); 
   CWnd::OnDestroy();
 }

Here the view deactivates itself when it's destroyed. As an aside—something for you to learn from—both of these frame dependencies could be avoided by sending notifications to the parent window instead of calling C++ methods. GetParentFrame could return a CWnd, not a CFrameWnd, since the important thing is that it's the top-level window—not that it's derived from any particular class. And instead of calling CFrameWnd methods, the view could send a notification like WM_IAMGOINGBYEBYENOW, which the "frame" (whether it's a CFrameWnd or a CFooWnd) would be responsible for handling appropriately. After all, it should be the frame, not the view, that decides what to do when a view is activated or destroyed. This is a general rule of thumb in any system; function calls go down (from parent to child), and events go up (from child to parent). A child class should never know what kind of container it lives in.
Ah well, life is never so perfect. Fortunately, MFC's misdemeanors are easily overcome. I wrote a CHtmlCtrl class (see Figure 1) that's just what you want: an HTML "view" you can use in a dialog or any window. CHtmlCtrl overrides both OnMouseActivate and OnDestroy to bypass the offending CView code.

 int CHtmlCtrl::OnMouseActivate(...)
 {
   // bypass CView doc/frame stuff
   return CWnd::OnMouseActivate(...);
 }
 void CHtmlCtrl::OnDestroy()
 {
   // bypass CView doc/frame stuff
   CWnd::OnDestroy(); 
 }

Hey, that was easy! The other thing CHtmlCtrl does is override PostNcDestroy.

 void CHtmlCtrl::PostNcDestroy() 
 {
   // Do nothing. Don't let CView get it.
 }

CView's implementation of PostNcDestroy does a "delete this" to destroy the view that's normal procedure. This is normal procedure for views, which are allocated directly from the heap. But controls customarily live as data members inside some other window object

 class CMyDialog ...
 {
   CHtmlCtrl m_htmlCtrl;
 }

in which case you don't want to delete the object in PostNcDestroy because it'll be deleted with the parent object.
With these modifications (OnMouseActivate, OnDestroy, and PostNcDestroy), CHtmlCtrl will work as a control in a dialog. To prove it, I wrote a little app called AboutHtml (see Figure 2) that displays an About box (see Figure 3) that's completely written in HTML. If you like the CStaticLink control I use to put Web links in all of my apps' About dialogs, you'll love AboutHtml. The HTML source, images, and sound file (yes, there's even sound) are all stored in the EXE itself as resources:

 // in AboutHtml.rc
 ABOUT.HTM  HTML DISCARDABLE "res\\about.htm"
 PD.JPG     HTML DISCARDABLE "res\\pd.jpg"
 OKUP.GIF   HTML DISCARDABLE "res\\okup.gif"
 OKDN.GIF   HTML DISCARDABLE "res\\okdn.gif"
 MOZART.WAV HTML DISCARDABLE "res\\mozart.wav"

It's important to use the real file names as the resource names so the browser can find them. In a normal Web page, if you code

 <IMG src="pd.jpg">

then pd.jpg is assumed to live in the current directory—that is, wherever the file containing the IMG element resides. In the case of a file stored in your EXE as a resource, the same is true. In this case, however, you have to give the browser a little help by adding the following code at the top of your HTML file:

 <BASE url="res://AboutHtml.exe/about.htm">

This tells the browser that the current "directory" is res://AboutHtml.exe, so when it encounters <IMG src="pd.jpg">, it will look for res://AboutHtml.exe/pd.jpg. Otherwise, it would look in the directory where your program file resides.

Figure 3 The About Dialog

In general, you can use res://modulename to access any resource in an executable or DLL. res: is a protocol just like http:, ftp:, file:, or mailto:. It says, "The first name in the path is a file name, and the second name is the name of a resource within that file." The browser does the rest.
To implement the About dialog, I wrote a class, CAboutDialog, that has a CHtmlCtrl member called m_page. Here's how CAboutDialog initializes itself:

 BOOL CAboutDialog::OnInitDialog()
 {
   VERIFY(CDialog::OnInitDialog());
   VERIFY(m_page.CreateFromStatic(IDC_HTMLVIEW, this));
   m_page.LoadFromResource(_T("about.htm"));
   return TRUE;
 }

CHtmlCtrl::CreateFromStatic is a handy function I wrote to simplify designing dialogs in the resource editor. It's way, way, WAY too much trouble to make an insertable COM object for something like this, so instead I created a blank static control with the ID I wanted in the position I wanted. Then I called CreateFromStatic, which created a CHtmlCtrl with the exact same ID, size, and position as the static, then destroyed the static. It's very effective. To launch the page, I called CHtmlCtrl::LoadFromResource, inherited from CHtmlView. Alternatively, I could have navigated to res://AboutHtml.exe/about.htm.
OK, where am I? I've shown you how CHtmlCtrl bypasses CView to live in a dialog instead of a frame. I've shown you how to write your HTML files and images so they can live as resources. I showed you how to create the HTML control and open it to a particular resource. There's just one thing I didn't explain. Can you guess? Shall I drag it out for another sentence?
How does CAboutDialog know when the user clicks the OK button—which isn't a button at all, but an image in the HTML file? Using JScript, the image changes from an up to a down state when you click it—but how does the dialog communicate with the app?
One way to find out when the user clicks an image or link is to grovel through the Dynamic HTML document hierarchy (using COM) to find the IMG element and then listen for its OnClick event. But that's way, way, way, WAY (four ways, one more than implementing an insertable object) too much trouble. Remember, when it comes to programming, laziness is a virtue.
In this case, there's a much simpler way. Suppose you make the button a hyperlink to a document called ok.

 <A href="ok"><IMG ...></A>

Now when the user clicks, the browser goes to the ok file. But before it does, control passes through CHtmlCtrl::OnBeforeNavigate2. CHtmlCtrl can do anything it wants.

 void CMyHtmlCtrl::OnBeforeNavigate2(
   LPCTSTR lpszURL,...,BOOL* pbCancel)
 {
   if (_tcscmp(lpszURL,_T("ok"))==0) {
     // "ok" clicked:
     *pbCancel=TRUE; // abort 
     // will close dialog    
    GetParent()->     
           SendMessage(WM_COMMAND,IDOK);
   }
 }

So ok isn't really the name of another file; it's a special name CHtmlCtrl interprets as the OK button. Pretty neat. To package this idea in a more coherent form, I invented a pseudo-protocol called app:. Instead of using ok, the actual link in about.htm is app:ok. Whenever CHtmlCtrl sees the browser trying to navigate to app:somewhere, it calls a new virtual function, CHtmlCtrl::OnAppCmd, with somewhere as the argument, and cancels navigation. So CMyHtmlCtrl doesn't override OnNavigate2; it overrides OnAppCmd.

 void CMyHtmlCtrl::OnAppCmd(
 LPCTSTR lpszWhere)
 {
   if (_tcsicmp(lpszWhere,
                _T("ok"))==0) {
   GetParent()->SendMessage
      (WM_COMMAND,IDOK);
   }
 }

You can put other links in your HTML file, like app:cancel, app:refresh, or app:whatever, and write your OnAppCmd handler to look for the strings "cancel", "refresh", and "whatever". It's like programming in Visual Basic®!
Now I just know that after reading about CHtmlCtrl everyone will race to their keyboards to download the code and tap in their new, improved About dialog. After all, the About box is the most fun part of the app, right? You can even implement Easter eggs; if the user clicks three times here and twice there, you can play a little jingle and launch a video of your dog licking peanut butter out of a thimble. No need to worry about performance or browser compatibility since you're running off the disk and it's always Microsoft® Internet Explorer.
But before you go wild, a word of caution: it does take a little while to load all those Internet Explorer DLLs. If it takes 10 seconds and an hourglass to run the About dialog, users may think your app was written by a bozo.

Q I need to work with a Microsoft Access 2000 database and Data Access Objects (DAO) 3.6 from C++ with MFC. When I try to use CDaoRecordset, I get an "Unrecognized database format" error message. MFC probably uses DAO 3.5. How can I open files in MFC that were created with Microsoft Access 2000?

Ing. Jozef Sakalos
Slovakia

A This question is also discussed in the Knowledge Base article Q236991 (http://support.microsoft.com/support/kb/articles/ Q236/9/91.asp), but since so many people have asked, I'll cover it here. The problem is that MFC is using the wrong DAO DLL. When you call AfxDaoInit to initialize DAO for MFC, MFC first determines which version of the DAO engine to load.

 // in daocore.cpp
 void AFXAPI AfxDaoInit()
 {
 •
 •
 •
   BYTE bUseDao = _AfxDetermineDaoVersion();
   switch (bUseDao) {
   case 35:
     // Use DAO350.DLL
     break;
   case 30:
     // Use DAO300.DLL
     break;
   case 36:
     // Use DAO360.DLL
     break;
   }
 }

_AfxDetermineDaoVersion is a macro that expands to 30, 35, or 36, depending on which version of MFC you have.

 #if _MFC_VER >= 0x0601
 #define _AfxDetermineDaoVersion() (36)
 #else
 #define _AfxDetermineDaoVersion() (35)
 #endif

The previous code only shows how _AfxDetermineDaoVersion expands when you link with a static MFC (_AFXDLL not #defined). If you're linking with MFC as a DLL (_AFXDLL #defined), _AfxDetermineDaoVersion expands to a real inline function:

 static inline BYTE _AfxDetermineDaoVersion() 
 {
   BYTE bReturn = 35;
   AFX_MODULE_STATE* pModuleState = AfxGetModuleState();
   if (pModuleState->m_dwVersion < 0x421)
     bReturn = 30;
   else if (pModuleState->m_dwVersion >= 0x0601)
     bReturn = 36;
   return bReturn;
 }

The only difference between these cases is that in the first situation, the MFC version number is hardcoded as _MFC_ VER. For dynamically linked projects, MFC gets the version from your module's state. This is required because apps with different MFC versions can potentially call the same MFC42.DLL. Either way, MFC uses its own version number to determine which version of DAO to use. If the MFC version is 0x0601 (6.1) or higher, MFC uses DAO 3.6, the version used by Microsoft Access 2000.
So in order to gain access to Microsoft Access 2000 databases, you need MFC version 6.1. There's only one problem: there is no version 6.1 of MFC. The current version is 6.0!

 // in afxver_.h
 #define _MFC_VER 0x0600

The only way I know to get MFC 6.1 requires a time-travel device. So the question is: what's going on here? If there's no version 6.1, why does daocore.cpp have 0x0601 in it? The obvious way to support a different DAO version would have been to put the DAO version number as an argument to AfxDaoInit—after all, why should the DAO version be tied to the MFC version? But who thinks of version numbers the first time they write the code? But once a signature for AfxDaoInit was chosen, the MFC folks were forever constrained because they had to maintain strict binary backward compatibility with MFC42.DLL. Adding an argument to AfxDaoInit would change the function signature and hence the DLL entries. So the problem confronting the Redmondtonians was: how to tell MFC to use the new DAO, without introducing any new functions or function arguments? Using the MFC version number provided a convenient, if kludgy, way. (Of course, I'm only guessing that's what happened.)
So, to use the latest DAO engine, all you have to do is make MFC pretend it's the mysterious nonexistent version 6.1. If you're building with MFC as an MFC DLL, all you have to do is write:

 AfxGetModuleState()->m_dwVersion = 0x0601; 
 AfxDaoInit();

That is, set the version number in your module state to 6.1 before you call AfxDaoInit. If you're the paranoid sort—and who isn't paranoid from time to time—you can save the original version and restore it after doing your business. A simple grep reveals, however, that _AfxDetermineDaoVersion is the only function in all of MFC that uses the mysterious 0x0601 version, so changing the version to 0x0601 should have no side effects.
If you're using the static MFC library, life is a little more difficult. The MSDN™ article mentioned earlier advises that you edit daocore.cpp and rebuild MFC. Yikes! That's a bit drastic for my taste. You should never rebuild MFC if you can avoid it. Better to confine whatever workarounds you need to your own project. Life is safer and more predictable if you make a hard and fast rule that the MFC libraries and code hierarchy are off limits. In fact, you should do what I do as soon as I install any new version of MFC or any SDK—set the read-only attribute on all the files.
But then how can you make MFC use DAO360.DLL in a static MFC build? Easy. Just copy the offending MFC source file (in this case, daocore.cpp) to your code directory, make the changes, and add it to your project. This is always a better way to modify MFC than munging MFC directly. When the linker needs a function or symbol from daocore.obj, it'll find the one in your modified version and, therefore, never need to load daocore.obj from MFC42.LIB. Of course, most MFC modules won't compile outside of their context; there are always some #include files from \mfc\src that you need. The easiest way to find them is just keep compiling and fixing until there are no more errors to fix. For daocore.cpp it turns out you need afximpl.h and daoimpl.h. afximpl.h is the MFC main internal include file, but in fact the only thing daocore.cpp needs from afximpl.h is _countof, so it's easier to copy the definition.

 // Add these lines to the top of daocore.cpp
 #include "daoimpl.h"
 #define _countof(array) \
   (sizeof(array)/sizeof(array[0]))
 #undef _MFC_VER
 #define _MFC_VER 0x0601

Once you add these lines to daocore.cpp and copy daoimpl.h to your project, daocore.cpp will compile with only a single warning, which you can safely ignore. And since you've redefined _MFC_VER to 0x0601, _AfxDetermineDaoVersion will now use DAO 3.6 (DAO360.DLL). Problem solved.
Just don't forget—this is only a stopgap measure! Once the Redmondtonians release the next MFC, you can return to life as usual. But you should remember this general technique: if you're absolutely, positively sure you need to modify MFC, don't modify the source directly. Instead, copy the module you want to change, plus any #include files and #defines it needs, and add it to your project. This method works whether you're linking with MFC as a static or dynamic library.

Have a question about programming in C or C++? Send it to Paul DiLascia at askpd@pobox.com

From the January 2000 issue of Microsoft Systems Journal.
Get it at your local newsstand, or better yet, subscribe.