テクニカルノート 21: コマンドとメッセージのルーティング

[アーティクル]
06/16/2023

Note

次のテクニカルノートは、最初にオンラインドキュメントの一部とされてから更新されていません。結果として、一部のプロシージャおよびトピックが最新でないか、不正になります。最新の情報について、オンラインドキュメントのキーワードで関係のあるトピックを検索することをお勧めします。

このノートでは、コマンドルーティングとディスパッチのアーキテクチャのほか、一般的なウィンドウメッセージのルーティングにおける高度なトピックについても説明します。

ここで説明するアーキテクチャの全般的な詳細 (特に Windows メッセージ、コントロール通知、コマンドの違い) については、Visual C++ を参照してください。このノートでは、印刷されたドキュメントに記載されている問題についてよく理解していることを前提とし、非常に高度なトピックのみを取り上げます。

コマンドルーティングとディスパッチに関する MFC 1.0 機能が MFC 2.0 アーキテクチャに進化

Windows には、メニューコマンド、アクセラレータキー、ダイアログコントロールの通知を提供するためにオーバーロードされる WM_COMMAND メッセージがあります。

MFC 1.0 では、CWnd 派生クラスのコマンドハンドラー (たとえば、"OnFileNew") を特定の WM_COMMAND に応答して呼び出せるようにすることで、それを少しだけ強化しました。これは、メッセージマップと呼ばれるデータ構造と合わせることで、非常に空間効率のよいコマンドメカニズムになります。

また、MFC 1.0 には、コントロール通知とコマンドメッセージを区別するための追加機能も用意されています。コマンドは 16 ビット ID (コマンド ID と呼ばれる場合もあります) で表されます。コマンドは、通常、CFrameWnd (つまり、メニュー選択または変換されたアクセラレータ) から始まり、他のさまざまなウィンドウにルーティングされます。

MFC 1.0 では、マルチドキュメントインターフェイス (MDI) の実装に対して、限られた意味でコマンドルーティングを使用していました (MDI フレームウィンドウは、コマンドをそのアクティブな MDI 子ウィンドウにデリゲートします)。

MFC 2.0 では、この機能が一般化され、コマンドを (ウィンドウオブジェクトだけでなく) より幅広いオブジェクトで処理できるよう拡張されました。これは、メッセージをルーティングするためのより明確で拡張性の高いアーキテクチャを提供し、コマンドの処理だけでなく UI オブジェクト (メニュー項目やツールバーのボタンなど) の更新にもコマンドターゲットルーティングを再利用して現在コマンドを使用できるかどうかを反映します。

コマンド ID

コマンドルーティングとバインドのプロセスの説明については、Visual C++ を参照してください。テクニカルノート 20 には、ID の名前付けに関する情報が含まれています。

コマンド ID には汎用プレフィックス "ID_" を使用します。コマンド ID は 0x8000 以上です。コマンド ID と同じ ID の STRINGTABLE リソースがある場合、メッセージ行またはステータスバーにはコマンドの説明文字列が表示されます。

アプリケーションのリソースでは、コマンド ID がいくつかの場所に表示されます。

メッセージ行プロンプトと同じ ID が設定されている 1 つの STRINGTABLE リソース内。
同じコマンドを呼び出す複数のメニュー項目に関連付けられている MENU リソース内 (多数ある可能性があります)
(上級) GOSUB コマンドのダイアログボタン内。

アプリケーションのソースコードでは、コマンド ID がいくつかの場所に表示されます。

アプリケーション固有のコマンド ID を定義する RESOURCE.H (または他のメインシンボルヘッダーファイル) 内。
場合によっては、ツールバーの作成に使用された ID 配列内。
ON_COMMAND マクロ内。
場合によっては、ON_UPDATE_COMMAND_UI マクロ内。

現在、MFC で 0x8000 以上のコマンド ID を必要とする実装は、GOSUB ダイアログまたはコマンドの実装のみです。

GOSUB コマンド (ダイアログでコマンドアーキテクチャを使用)

コマンドをルーティングして有効にする際のコマンドアーキテクチャは、フレームウィンドウ、メニュー項目、ツールバーのボタン、ダイアログバーのボタン、その他のコントロールバーのほか、必要に応じて更新してコマンドやコントロール ID をメインのコマンドターゲット (通常はメインフレームウィンドウ) にルーティングするよう設計されたユーザーインターフェイス要素で問題なく動作します。そのメインのコマンドターゲットは、必要に応じて、コマンドまたはコントロールの通知を他のコマンドターゲットオブジェクトにルーティングする場合があります。

ダイアログ (モーダルまたはモードレス) では、ダイアログコントロールのコントロール ID を適切なコマンド ID に割り当てると、コマンドアーキテクチャの一部の機能が役立ちます。ダイアログのサポートは自動的には行われないため、追加のコードの記述が必要になる場合があります。

これらのすべての機能が正常に機能するには、コマンド ID を 0x8000 以上にする必要があります。多くのダイアログは同じフレームにルーティングされるため、共有コマンドは 0x8000 以上にする必要があるのに対し、特定のダイアログにある非共有の IDC は 0x7FFF 以下にする必要があります。

通常のモーダルダイアログに通常のボタンを配置する際、そのボタンの IDC を適切なコマンド ID に設定できます。ユーザーがこのボタンを選択すると、ダイアログの所有者 (通常はメインフレームウィンドウ) は、その他のコマンドと同じようにそのコマンドを取得します。これは GOSUB コマンドと呼ばれます。通常、別のダイアログ (最初のダイアログの GOSUB) を表示するために使用されるためです。

また、ダイアログで CWnd::UpdateDialogControls 関数を呼び出し、メインフレームウィンドウのアドレスを渡すこともできます。この関数は、フレーム内にコマンドハンドラーがあるかどうかに基づいて、ダイアログコントロールを有効または無効にします。この関数は、アプリケーションのアイドルループでコントロールバーに対して自動的に呼び出されますが、この機能を使用する通常のダイアログに対しては直接呼び出す必要があります。

ON_UPDATE_COMMAND_UI が呼び出される場合

プログラムのすべてのメニュー項目の有効またはオンの状態を維持し続けることは、負荷の大きい問題になるおそれがあります。一般的な方法は、ユーザーがポップアップを選択した場合にのみメニュー項目を有効またはオンにすることです。 MFC 2.0 で実装した CFrameWnd は、WM_INITMENUPOPUP メッセージを処理し、コマンドルーティングアーキテクチャを使用して ON_UPDATE_COMMAND_UI ハンドラーでメニューの状態を確認します。

また、CFrameWnd は、WM_ENTERIDLE メッセージを処理して、ステータスバー (メッセージ行とも呼ばれます) で選択されている現在のメニュー項目を記述します。

Visual C++ で編集されたアプリケーションのメニュー構造は、WM_INITMENUPOPUP 時に使用可能なコマンドを表すために使用されます。 ON_UPDATE_COMMAND_UI ハンドラーは、メニューの状態またはテキストを変更することも、高度な用途 (File MRU リストや OLE Verb のポップアップメニューなど) では、メニューが描画される前にメニュー構造を変更することもできます。

同じような ON_UPDATE_COMMAND_UI 処理は、アプリケーションがアイドルループに入ると、ツールバー (およびその他のコントロールバー) に対して実行されます。コントロールバーの詳細については、"クラスライブラリリファレンス" およびテクニカルノート 31 を参照してください。

入れ子になったポップアップメニュー

入れ子になったメニュー構造を使用している場合は、ポップアップメニューの最初のメニュー項目の ON_UPDATE_COMMAND_UI ハンドラーが 2 つの異なるケースで呼び出されることに気付きます。

1 つ目は、ポップアップメニュー自体に対して呼び出されます。ポップアップメニューには ID がなく、ポップアップメニューの最初のメニュー項目の ID を使用してポップアップメニュー全体を参照するため、これは必要です。このケースでは、CCmdUI オブジェクトの m_pSubMenu メンバー変数は NULL 以外の値になり、ポップアップメニューを指します。

2 つ目は、ポップアップメニューのメニュー項目が描画される直前に呼び出されます。このケースでは、ID は最初のメニュー項目だけを参照するため、CCmdUI オブジェクトの m_pSubMenu メンバー変数は NULL になります。

これにより、ポップアップメニューをそのメニュー項目と区別できるようになりますが、メニューに対応したコードを記述することが必要になります。たとえば、次の構造を使用した入れ子になったメニューがあるとします。

File>
    New>
    Sheet (ID_NEW_SHEET)
    Chart (ID_NEW_CHART)

ID_NEW_SHEET コマンドと ID_NEW_CHART コマンドは、個別に有効または無効にすることができます。 2 つのいずれかを有効にする場合は、New ポップアップメニューを有効にする必要があります。

ID_NEW_SHEET のコマンドハンドラー (ポップアップの最初のコマンド) は次のようになります。

void CMyApp::OnUpdateNewSheet(CCmdUI* pCmdUI)
{
    if (pCmdUI->m_pSubMenu != NULL)
    {
        // enable entire pop-up for "New" sheet and chart
        BOOL bEnable = m_bCanCreateSheet || m_bCanCreateChart;
        // CCmdUI::Enable is a no-op for this case, so we
        // must do what it would have done.
        pCmdUI->m_pMenu->EnableMenuItem(pCmdUI->m_nIndex,
            MF_BYPOSITION |
            (bEnable  MF_ENABLED : (MF_DISABLED | MF_GRAYED)));

        return;
    }
    // otherwise just the New Sheet command
    pCmdUI->Enable(m_bCanCreateSheet);
}

ID_NEW_CHART のコマンドハンドラーは、通常の更新コマンドハンドラーであり、次のようになります。

void CMyApp::OnUpdateNewChart(CCmdUI* pCmdUI)
{
    pCmdUI->Enable(m_bCanCreateChart);
}

ON_COMMAND と ON_BN_CLICKED

ON_COMMAND と ON_BN_CLICKED のメッセージマップマクロは同じです。 MFC のコマンドおよびコントロールの通知ルーティングメカニズムでは、ルーティング先を決定するためにコマンド ID のみを使用します。コントロール通知コードがゼロ (BN_CLICKED) のコントロール通知は、コマンドと解釈されます。

Note

実際、すべてのコントロール通知メッセージは、コマンドハンドラーチェーンを経由します。たとえば、ドキュメントクラスで EN_CHANGE のコントロール通知ハンドラーを記述することは技術的に可能です。通常、これはお勧めしません。この機能の実用例はほとんどなく、この機能は ClassWizard でサポートされていないためです。また、この機能を使用すると、脆弱なコードになる可能性もあります。

ボタンコントロールの自動無効化を無効にする

ボタンコントロールをダイアログバー、または独自に CWnd::UpdateDialogControls を呼び出す場所を使用しているダイアログに配置すると、ON_COMMAND または ON_UPDATE_COMMAND_UI ハンドラーがないボタンはフレームワークによって自動的に無効になることがわかります。場合によっては、ハンドラーはなくてもかまいませんが、ボタンを有効なままにしておく必要はあります。これを実現する最も簡単な方法は、ダミーのコマンドハンドラーを追加し (ClassWizard で簡単に実行できます)、その中では何も実行しないことです。

Windows メッセージのルーティング

次に、MFC クラスに関するより高度なトピックと、Windows メッセージのルーティングやその他のトピックが MFC クラスに与える影響について説明します。ここに記載されている情報は、簡単に説明したものにすぎません。パブリック API の詳細については、"クラスライブラリリファレンス" を参照してください。実装の詳細については、MFC ライブラリのソースコードを参照してください。

すべての CWnd 派生クラスにとって非常に重要なトピックであるウィンドウのクリーンアップの詳細については、テクニカルノート 17 を参照してください。

CWnd の問題

実装メンバー関数 CWnd:: OnChildNotify は、子ウィンドウ (コントロールとも呼ばれます) がその親 (または "所有者") に送られるメッセージ、コマンド、およびコントロール通知をフックするか、それに関する通知を受けるための強力で拡張可能なアーキテクチャを提供します。子ウィンドウ (またはコントロール) が C++ の CWnd オブジェクトそのものである場合、仮想関数 OnChildNotify は、最初に、元のメッセージのパラメーター (つまり、MSG 構造体) を使用して呼び出されます。子ウィンドウは、メッセージをそのまま残すか、処理するか、親のメッセージを変更する (まれ) ことができます。

既定の CWnd 実装は、以下のメッセージを処理し、OnChildNotify フックを使用して子ウィンドウ (コントロール) が最初にメッセージにアクセスできるようにします。

WM_MEASUREITEM と WM_DRAWITEM (自己描画の場合)
WM_COMPAREITEM と WM_DELETEITEM (自己描画の場合)
WM_HSCROLL と WM_VSCROLL
WM_CTLCOLOR
WM_PARENTNOTIFY

OnChildNotify フックは、オーナー描画メッセージを自己描画メッセージに変更するために使用されることがわかります。

OnChildNotify フックに加え、スクロールメッセージにはさらなるルーティング動作があります。 WM_HSCROLL および WM_VSCROLL メッセージのスクロールバーとソースの詳細については、以下を参照してください。

CFrameWnd の問題

CFrameWnd クラスでは、コマンドルーティングとユーザーインターフェイスの更新の実装の大部分を提供します。これは主にアプリケーションのメインフレームウィンドウ (CWinApp::m_pMainWnd) に使用されますが、すべてのフレームウィンドウに適用されます。

メインフレームウィンドウは、メニューバーのあるウィンドウで、ステータスバーまたはメッセージ行の親です。コマンドルーティングと WM_INITMENUPOPUP については、上記の説明を参照してください。

CFrameWnd クラスでは、アクティブなビューの管理を提供します。次のメッセージは、アクティブなビューを通じてルーティングされます。

すべてのコマンドメッセージ (アクティブなビューは最初にこれらにアクセスします)。
兄弟スクロールバーからの WM_HSCROLL および WM_VSCROLL メッセージ (下記を参照)。
WM_ACTIVATE (および MDI の場合は WM_MDIACTIVATE) は仮想関数 CView::OnActivateView の呼び出しに変換されます。

CMDIFrameWnd または CMDIChildWnd の問題

どちらの MDI フレームウィンドウクラスも CFrameWnd から派生しているため、CFrameWnd で提供される同じようなコマンドルーティングとユーザーインターフェイスの更新に対して両方とも有効になります。一般的な MDI アプリケーションでは、メインフレームウィンドウ (つまり CMDIFrameWnd オブジェクト) のみがメニューバーとステータスバーを保持するため、コマンドルーティングの実装の主なソースとなります。

一般的なルーティング方式では、アクティブな MDI 子ウィンドウが最初にコマンドにアクセスします。既定の PreTranslateMessage 関数は、MDI 子ウィンドウ (最初) と MDI フレーム (2 番目) 両方のアクセラレータテーブルに加え、通常は TranslateMDISysAccel によって処理される標準の MDI システムコマンドアクセラレータ (最後) を処理します。

スクロールバーの問題

スクロールメッセージ (WM_HSCROLL/OnHScroll や WM_VSCROLL/OnVScroll) を処理する際は、スクロールバーのメッセージの発生元に依存しないようにハンドラーのコードを記述するようにしてください。これは一般的な Windows の問題ばかりではありません。スクロールメッセージは、実際のスクロールバーコントロール、またはスクロールバーコントロールではない WS_HSCROLL/WS_VSCROLL スクロールバーから取得されている可能性があるためです。

MFC では、スクロールバーコントロールをスクロールするウィンドウの子または兄弟として使用できるように拡張されています (実際には、スクロールバーとスクロールするウィンドウの間の親子関係は何でもかまいません)。これは、スプリッターウィンドウを使用した共有スクロールバーの場合に特に重要です。 CSplitterWnd の実装の詳細 (共有スクロールバーの問題の詳細を含む) については、テクニカルノート 29 を参照してください。

ちなみに、作成時に指定されたスクロールバースタイルがトラップされ、Windows に渡されていない CWnd 派生クラスが 2 つあります。作成ルーチンに渡されるときに、WS_HSCROLL と WS_VSCROLL は個別に設定できますが、作成後に変更することはできません。当然ながら、作成したウィンドウの WS_SCROLL スタイルを表すビットを直接テストまたは設定しないでください。

CMDIFrameWnd では、Create または LoadFrame に渡すスクロールバースタイルを使用して、MDICLIENT を作成します。スクロール可能な MDICLIENT 領域 (Windows プログラムマネージャーなど) を使用する場合は、CMDIFrameWnd の作成に使用するスタイルの両方のスクロールバースタイル (WS_HSCROLL | WS_VSCROLL) を設定してください。

CSplitterWnd では、スクロールバースタイルがスプリッター領域の特殊な共有スクロールバーに適用されます。静的なスプリッターウィンドウでは、通常、いずれのスクロールバースタイルも設定しません。動的なスプリッターウィンドウでは、通常、分割する方向に対してスクロールバースタイルを設定します。つまり、行を分割する場合は WS_HSCROLL、列を分割する場合は WS_VSCROLL です。

次の方法で共有

テクニカルノート 21: コマンドとメッセージのルーティング

コマンドルーティングとディスパッチに関する MFC 1.0 機能が MFC 2.0 アーキテクチャに進化

コマンド ID

GOSUB コマンド (ダイアログでコマンドアーキテクチャを使用)

ON_UPDATE_COMMAND_UI が呼び出される場合

入れ子になったポップアップメニュー

ON_COMMAND と ON_BN_CLICKED

ボタンコントロールの自動無効化を無効にする

Windows メッセージのルーティング

CWnd の問題

CFrameWnd の問題

CMDIFrameWnd または CMDIChildWnd の問題

スクロールバーの問題

関連項目

フィードバック

その他のリソース

次の方法で共有

テクニカル ノート 21: コマンドとメッセージのルーティング

コマンド ルーティングとディスパッチに関する MFC 1.0 機能が MFC 2.0 アーキテクチャに進化

コマンド ID

GOSUB コマンド (ダイアログでコマンド アーキテクチャを使用)

ON_UPDATE_COMMAND_UI が呼び出される場合

入れ子になったポップアップ メニュー

ON_COMMAND と ON_BN_CLICKED

ボタン コントロールの自動無効化を無効にする

Windows メッセージのルーティング

CWnd の問題

CFrameWnd の問題

CMDIFrameWnd または CMDIChildWnd の問題

スクロール バーの問題

関連項目

フィードバック

その他のリソース

テクニカルノート 21: コマンドとメッセージのルーティング

コマンドルーティングとディスパッチに関する MFC 1.0 機能が MFC 2.0 アーキテクチャに進化

GOSUB コマンド (ダイアログでコマンドアーキテクチャを使用)

入れ子になったポップアップメニュー

ボタンコントロールの自動無効化を無効にする

スクロールバーの問題