Win32プログラミングノート --- 入力 ---

蛇足：MFC内部の処理を見てみよう

一体全体どのようにしてCHistoryWnd::OnUpdateXXXXが呼ばれているのか、MFCではどのようにコマンドアップデートを行っているのか、必ずしも知らなくても構わないことですが、ちょっと追っかけてみることにしましょう。 MFCの動きがどうも良く分からない、というときの解析の参考にでもしてください。

CHistoryWnd::OnUpdateClearHistory()が呼び出されたときのスタックは、次のようになっています。


CHistoryWnd::OnUpdateClearHistory()
DispatchCmdMsg()
CCmdTarget::OnCmdMsg()
CHistoryWnd::OnCmdMsg()
CDicntView::OnCmdMsg()
CFrameWnd::OnCmdMsg()
CCmdUI::DoUpdate()
CFrameWnd::OnInitMenuPopup()
CMainFrame::OnInitMenuPopup()
CWnd::OnWndMsg()
CWnd::WindowProc()
AfxCallWndProc()
AfxWndProc()
AfxWndProcBase()
USER32! 77e51d6a()
USER32! 77e51024()
NTDLL! 77f65e6b()
CMenu::TrackPopupMenu()
CHistoryWnd::OnContextMenu()
CWnd::OnWndMsg()
CWnd::WindowProc()
AfxCallWndProc()
AfxWndProc()
AfxWndProcBase()
USER32! 77e51d6a()
USER32! 77e51024()
NTDLL! 77f65e6b()
USER32! 77e54555()
COMCTL32! 77bd2bb3()
USER32! 77e52793()
USER32! 77e5849c()
CWnd::DefWindowProcA()
CWnd::WindowProc()
AfxCallWndProc()
AfxWndProc()
AfxWndProcBase()
USER32! 77e51d6a()
USER32! 77e51024()
NTDLL! 77f65e6b()
USER32! 77e54555()
COMCTL32! 77bd2bb3()
USER32! 77e52793()
USER32! 77e5849c()

TrackPopupMenuの前までは、WM_CONTEXTMENUの処理が見えます。コモンコントロールからダイアログへ、WM_SETCONTEXTMENUがSendされている様子が伺えます。

そこから、CWnd::OnWndMsg()でWM_INITPOPUPMENUが処理され、CMainFrame()::OnInitPopupMenu()へ渡ります。その中で、CCmdUIオブジェクトが作成され、そのDoUpdate()が呼び出されていることが分かります。

CCmdUI::DoUpdate()から連鎖的に呼び出されるOnCmdMsg()で、最終的には、どれかのクラスのOnUpdateXXXX が呼び出されます。呼び出される優先順位は、次のようになります。

アクティブビュー → アクティブドキュメント → フレーム → アプリケーション

CCmdUI::DoUpdate()

CCmdUI::DoUpdate()は、フレームウィンドウのOnCmdMsg()を呼び出します。OnCmdMsg()は、 OnCmdMsg()の呼び出しで、this->Enable()やSetCheck()が呼ばれますが、その結果に応じてCCmdUIはメニュー項目のEnable/Disableやチェックマークの付与を行います。

CFrameWnd::OnCmdMsg()

フレームウィンドウのOnCmdMsg()は、アクティブビューを探し出し、そのOnCmdMsg()を呼びます。

CFrameWnd::OnCmdMsg()
{
    // アクティブビューのOnCmdMsg()
    if (GetActiveView()->OnCmdMsg())
        return TRUE;
    // フレームのOnCmdMsg()
    if (CWnd::OnCmdMsg())
        return TRUE;
    // アプリケーションクラスのOnCmdMsg()
    if (AfxGetApp()->OnCmdMsg())
        return TRUE;
    return FALSE;   // コマンドは処理されなかった
}

CView::OnCmdMsg()

通常のビューのOnCmdMsg()では、

CView::OnCmdMsg()
{
    // ビューでハンドルされるかどうか
    if (CWnd::OnCmdMsg())
        return TRUE;
    // ドキュメントでハンドルされるか？
    if (GetDocument()->OnCmdMsg())
        return TRUE;
    return FALSE;
}

となります(上の例ではCView::OnCmdMsg()をオーバーライドしているので、CHistoryWnd::OnCmdMsg()がビューのハンドラよりも先に呼ばれますが)。

CCmdTarget::OnCmdMsg() -- コマンドメッセージのディスパッチ

どのクラスのOnCmsgMsg()も、最終的には CWnd::OnCmdMsg() --- は定義されていないので、さらにその基本クラスの CCmdTarget::OnCmdMsg() へたどり着きます。CCmdTarget::OnCmdMsg()は、メッセージマップを手繰り、コマンドハンドラまたはコマンドアップデートハンドラを実際に呼び出します。

OnCmdMsg()は、メッセージマップを手繰っていき、エントリが見つかればコマンドメッセージをディスパッチします。

メッセージマップにハンドラが見つからなければ、基本クラスのメッセージマップを次々に探します。最後までエントリが見つからなければ、FALSEを返し、コマンドメッセージが処理されなかったことを示します。

CCmdTarget::OnCmdMsg()
{
    AFX_MSGMAP* pMap = GetCommandMap();
    while (pMap != NULL) {
        AFX_MSGMAP_ENTRY* pEntry = AfxFindMessageEntry();
        if (pEntry != NULL) {
            return DispatchCmdMsg(...);     //メッセージのディスパッチ
        }
        pMap = pMap->pBaseMap;  // 親クラスのメッセージマップ
    }
    return FALSE;
}

ちなみに、AFX_MSGMAP_ENTRYは次のように定義されています。

struct AFX_MSGMAP_ENTRY
{
    UINT nMessage;   // windows message
    UINT nCode;      // control code or WM_NOTIFY code
    UINT nID;        // control ID (or 0 for windows messages)
    UINT nLastID;    // used for entries specifying a range of control id's
    UINT nSig;       // signature type (action) or pointer to message #
    AFX_PMSG pfn;    // routine to call (or special value)
};

Win32プログラミングノート --- 入力 ---

ダイアログ中のエディットコントロールでタブキーを入力するためのハック

モードレスダイアログから、メインウィンドウのキーボードアクセラレータを使えるようにする

モードレスダイアログのメニューハンドラでコマンドアップデート機構を利用する

MFCのコマンド処理機構

蛇足：MFC内部の処理を見てみよう

CCmdUI::DoUpdate()

CFrameWnd::OnCmdMsg()

CView::OnCmdMsg()

CCmdTarget::OnCmdMsg() -- コマンドメッセージのディスパッチ