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。

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.