View和Control的区别（如何在对话框上使用CView类）

View和Control的区别（如何在对话框上使用CView类）

　　CView继承类，和其他窗口类的区别，很重要的就是对CDocument类和CFrameWnd类的操作，而其中，涉及CDocument类的操作，都进行了有效性判断（m_pDocument != NULL)，CView类初始化的时候，m_pDocument = NULL，因此并不影响CView类作为控件的使用。涉及CFrame类的操作，有这么几个地方：

　　第一个地方：CView::OnDestroy()。

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

　　第二个地方：CView::OnActivateFrame()。

void CView::OnActivateFrame(UINT /*nState*/, CFrameWnd* /*pFrameWnd*/)
{
}

　　这里，其实是空的，在CView继承类中，只有CFormView类继承了这个虚函数

void CFormView::OnActivateFrame(UINT nState, CFrameWnd* /*pFrameWnd*/)
{
 if (nState == WA_INACTIVE)
  SaveFocusControl();     // save focus when frame loses activation
}

　　实际上都不需要真的CFrame指针，对CView类作为控件使用没有障碍。

　　第三个地方：CView::OnMouseActivate()。

int CView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
{
 int nResult = CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
 if (nResult == MA_NOACTIVATE || nResult == MA_NOACTIVATEANDEAT)
  return nResult;   // frame does not want to activate

 CFrameWnd* pParentFrame = GetParentFrame();
 if (pParentFrame != NULL)
 {
  // eat it if this will cause activation
  ASSERT(pParentFrame == pDesktopWnd || pDesktopWnd->IsChild(pParentFrame));

  // either re-activate the current view, or set this view to be active
  CView* pView = pParentFrame->GetActiveView();
  HWND hWndFocus = ::GetFocus();
  if (pView == this &&
   m_hWnd != hWndFocus && !::IsChild(m_hWnd, hWndFocus))
  {
   // re-activate this view
   OnActivateView(TRUE, this, this);
  }
  else
  {
   // activate this view
   pParentFrame->SetActiveView(this);
  }
 }
 return nResult;
}

　　另外，在CView::PostNcDestroy()，实现了CView类的自我销毁，这是因为CView类是可以动态生成的（DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE）。

// self destruction
void CView::PostNcDestroy()
{
 // default for views is to allocate them on the heap
 //  the default post-cleanup is to 'delete this'.
 //  never explicitly call 'delete' on a view
 delete this;
 

　　基本上，修改了CView继承类的这几个地方，直接返回不要调用基类相应的成员函数，就可以在对话框上使用。

　　下面举例，用向导生成对话框应用程序，对话框类为CMyDigalog。

　　从CHTMLView类继承一个CHTMLCtrl类，建立相应的消息处理函数并修改以下几个地方：

// CHTMLCtrl 消息处理程序

int CHTMLCtrl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
{
 // TODO: 在此添加消息处理程序代码和/或调用默认值
 return CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);

 //return CHtmlView::OnMouseActivate(pDesktopWnd, nHitTest, message);
}

void CHTMLCtrl::OnDestroy()
{
 //CHtmlView::OnDestroy();

 // TODO: 在此处添加消息处理程序代码
 CWnd::OnDestroy();
}

void CHTMLCtrl::PostNcDestroy()
{
 // TODO: 在此添加专用代码和/或调用基类

 //CHtmlView::PostNcDestroy();
}

void CHTMLCtrl::OnActivateFrame(UINT nState, CFrameWnd* pDeactivateFrame)
{
 // TODO: 在此添加专用代码和/或调用基类

 //CHtmlView::OnActivateFrame(nState, pDeactivateFrame);
}

　　增加一个成员函数CreateFromCtrl：

public:
 BOOL CreateFromCtrl(UINT nID, CWnd* pParent);

　　这个函数通过对话框上的控件创建一个CHTMLCtrl控件，目的是在对话框设计的时候便于布局：

BOOL CHTMLCtrl::CreateFromCtrl(UINT nID, CWnd* pParent)
{
 if (!pParent || !pParent->GetSafeHwnd())
  return FALSE;
 CWnd *pCtrl = pParent->GetDlgItem(nID);
 if (!pCtrl)
  return FALSE;
 CRect rcCtrl;
 pCtrl->GetWindowRect(rcCtrl);
 pParent->ScreenToClient(rcCtrl);
 UINT style = ::GetWindowLong(pCtrl->GetSafeHwnd(), GWL_STYLE);
 pCtrl->DestroyWindow();

 return Create(NULL, NULL, style | WS_CHILD | WS_VISIBLE, rcCtrl, pParent, nID, NULL);

}

　　还应注意，默认的从CView继承的类，其构造函数和析构函数是protected的，需要修改成public。

　　还应注意，默认的从CView继承的类，其构造函数和析构函数是protected的，需要修改成public。

public:
 CHTMLCtrl();           // 动态创建所使用的受保护的构造函数
 virtual ~CHTMLCtrl();

　　然后，在对话框模板中（使用资源编辑器），插入一个Static Text控件，ID为IDC_HTML。

　　在对话框头文件中，插入包含文件：

#include "htmlctrl.h"

　　增加CHTMLCtrl类型的成员变量：

 CHTMLCtrl m_ctlHTML;

 　　在对话框初始化的时候，创建这个CHTMLCtrl控件：

BOOL CMyDialog::OnInitDialog()
{
 CDialog::OnInitDialog();
 ...

 m_ctlHTML.CreateFromCtrl(IDC_HTML, this);

 return TRUE;
}

　　下面，再添加一个按钮，在按钮的消息响应函数中打开HTML文件：

void CMyDialog::OnSysCommand(UINT nID, LPARAM lParam)
{
 if ((nID & 0xFFF0) == IDM_ABOUTBOX)
 {
  CAboutDlg dlgAbout;
  dlgAbout.DoModal();
 }
 else
 {
  CDialog::OnSysCommand(nID, lParam);
 }
}

　　　本文参考MSDN上的一篇文章：MSJ 2000中的C++ Q&A，原文有关部分附在后面。

附：原文

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 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.