Windows C/C++０４章　WnidowBuild　０１／０２

Windows C/C++　検証報告プロジェクト：画面構成　WindowBuild　2025/12/13

※　ここでは、オブジェクト指向の規律および、マイクロソフト独自仕様が濃すぎてもはやＣ／Ｃ＋＋ではないリソース／マクロはできるだけ除外しながら動作確認、正しいかどうか以前の前段階としての Windows プログラムを介しての Microsoft の内部的な仕組みの理解のための検証報告が、ここでの主目的となる。その初期準備の経緯は０３章で説明している。

※　ここでは、Windows 10/11 のＰＣが対象であること、そして０２章で紹介している Microsoft Visual Stutio Community 2026（　無料版 Visual C/C++ 開発環境　）のインストール環境を前提に、話を進めている。

※　ここではキレハシ説明ばかりなものは避ける、特に、よそのこと道義外のことにとやかくケンカ腰の前の、なぜそうでなければならないのか／なぜそうしたのかの究明的な経緯や関連が全く読み取れない（　教育機関の規律絶対およびオブジェクト指向の規律絶対の低次元序列権威のような、最初から最後まで何もかもがうやむやな世の中の正しさとやらのたらい回し合い　）、すなわち目先の利害次第のただの性善説放任主義・偽善憎悪・老害浪費をだらしなく乱立拡散させ合っているだけのその上同士失格の怠慢の顔色を上から順番に旧廃策的に踏みにじり合う次の段階のための説明責任、すなわち上同士視点といえる等族義務の手本の作り合い（　＝　近代評議会的な品性規律といえる論述整理　＝　年期計画的な式目整備の原本　＝　上同士視点の敷居交流といえる等族指導の基準　）を重視、当ブログでのその動機・方針を０１章で説明している。ここでは検証報告の内容に応じて、できるだけ実際の動作確認もできるよう、プロジェクトファイルまるごとを順次アップロードしていく方針にしている。

※　当ブログでは　統合前時代　という言葉をよく使うため先に説明しておくと、これは Windows が 95 / 98 系と NT 4.0 / 2000 系が統合されることになった Windows XP よりも前のそれらの時代のことを指す。当ブログ筆者は NT 4.0 / 2000 の方での関わりが強かったことで　統合前 32 Bit 時代　といういい方をしている場合は、32 Bit 化本格発足となった NT4.0 以来の Windows API（　32 Bit 本格化当時の Windows 標準内部仕様　）の意味が強い。

今回は、先にプロジェクトファイルのダウンロードの案内から始めるが、ファイル名の所で　右ボタンメニュー　リンクを新しいタブで開く　でアップロード画面を表示することを推奨する。

WindowBuild_2Project.zip

※　ウイルスチェックソフト：ソースネクストＺＥＲＯスーパーセキュリティ 2025/12/08 最新情報 Ver 27.0.52.261 でチェック済み

混乱が無いよう念のため、このアップロードファイルについて案内しておく。

リンクを新しいタブで開く　でこちらの

Microsoft サービス OneDrive 画面が表示されたら、左上の　↓　ダウンロード　か、中央の　　ダウンロード　　を押すとダウンロードが行われるが、2 MB ほどと少ないためすぐに完了する。

ダウンロードをすると、エクスプローラーからの、例のダウンロードフォルダに保有されるが、

Windows 11 での場合だと、この左枠側のダウンロードフォルダではツリー表示がされないようであるため、ダウンロードファイルを右クリックメニューで　切り取り・貼り付け　で、いったんどこかのフォルダに移動する。

今回のアップロードファイルの中には、WindowBuildTrial と WndowBuild のふたつのプロジェクトが入っているため、

この階層の状態にし、右側枠の方のふたつを両選択、その上で右クリックメニューでコピー、

プロジェクトファイル群を管理している場所（　当ブログ筆者の場合は C:\FilesVC\ で管理している　）に貼り付けすると、中が取り出せる。

説明の順番としてまず WindowBuildTrial の方から紹介する。

そのフォルダに入っている slnx のプロジェクトファイルで Visual Studio を起動する。

ダウンロードによるプロジェクトデータは、操作履歴は除外してあるため、最初の読み込みは少し時間がかかる。

ダウンロードファイルによる初回読み込み時に

この確認画面が出てしまう場合は、当アップロードファイルは最新情報のウイルスチェックソフトでチェック済みおよび、怪しげな仕込みなども一切していないため　信頼して実行　で進めてもらってよい。

Visual Studio が起動したら、まず右枠の方を　ソリューションエクスプローラー　のタブであることを確認し、

赤丸で各ファイルを展開、メイン部分である WindowBuildTrial.cpp をダブルクリック、左編集側に表示させる。

※　ソリューションエクスプローラー　が急に無くなったり、間違えて　Ｘ　を押したりして見失ってしまった場合は、上部メニュー群　表示（Ｖ）　内　ソリューション　エクスプローラー（Ｐ）　で再表示。

メイン部分 WindowBuildTrial.cpp の方の、上から３つ目の手続き（　関数。プロシージャ　）となる WindowBuildTrial 手続きの所の

Ａ．設定値群

この記述群と、そのすぐ近くの下にある

Ｂ．設定値による部品追加群（　Windows 標準 API CreateWindowEx。User32.dll　）

それら記述群を見ながら F5 キーでの動作確認で見ていく。

今回の WindowBuildTrial の画面ではまず、メインウインドウに計１５個の部品が設置された例になる。

※　先にひと通り触ってもらっても構わない。今回の WindowBuildTrial および WindowBuild は、変更がけも含める書き込み・更新処理は一切入れていない、つまりどのような操作をしても参照しかしておらずどこかを消失させたり壊してしまう等は一切起きないため、そこは安心して触ってもらってよい。

※　対象パスの所に入力されているフォルダ位置を元に、LISTBOX の方にフォルダ一覧が表示されるようになっている。LISTBOX 側に項目がある場合、キーボードの上下キーやマウス左クリックでセル選択が可能。エンターキーでそのフォルダ内に移動、一番上の　．　でエンターで前の階層フォルダ場所に移動する動作にしてある。LISTBOX は名簿管理上の人物名だったり、在庫管理上の品種名だったり、また種別や工程といった概念を項目化する等、多様な使い方ができて、Windows の基本のひとつとして使い方に慣れておくと設計の手助けになる。ここでは LISTBOX をこのような動作仕様にもできるという例で紹介してみた。

※　この画面構成例は、32 Bit 主導化の Windows 95 / Windows NT 4.0 時代の機能しか使っていないが、実質はドットネット成立前 16 Bit / 32 Bit 互換 Windows 3.1 時代と大差ない旧基本機能だけで構成している。そのため LISTBOX の内在機能の、例えば文字列コードによる昇順／降順の判定基準が３０年前だったり、見た目にしても古さが目立つものの、機能的には現在でも十分活用できる。64 Bit Windows でも当時の仕様が残存し、使う分には特に問題ないことがこの例から窺える。

対象パス、入力関連、文字入力、数値入力と書かれた４個の文字列の静的部品（　STATIC。表記用部品　）および、左側の枠囲いもそれぞれ１部品、表示用部品が計５／１５になる。

画面の見た目からだと解りにくいが、チェックボックス１～３の文字列と、ボタン内の文字列については、動的部品（　入力操作部品　）に書かれた文字列になる。

１　フォルダパス文字列入力用の項目　：　２　参照ボタン　：　３　（　ここではフォルダ表示用の　）リストボックス　：　４　文字列入力項目　：　５　数値入力項目　：　６～８　チェックボックス１～３　：　９　全選択ボタン　：　１０　初期化ボタン

と数え、動的部品（　STATIC でないもの　）は計１０／１５、ウインドウハンドル管理（　Windows プログラムで大事な部分。意味を順述　）の総計としてはメインウインドウも含めて全部で１６個になる。

※　０２章で触れたが、Visual Studio は Community 2026 現在も、フォントサイズ設定値が８か１１になっていると、横表記が途中からズレ始めるという古くからの小欠陥がいまだに修正されていないため、９、１０や、１２以上等の設定を推奨する。

Ｂ．設定値による部品追加群（　Windows 標準 API CreateWindowEx。user32.dll　）　の、この１～５の赤枠について説明していく。

＜１　部品の種類＞

　部品の種類の指定で、当ブログ説明では STATIC、EDIT、LISTBOX、BUTTON の４種のみに限定することにしたが、CreateWindowEx の仕様では使える種類はもっとあることが

　CreateWindowExW 関数 (winuser.h) - Win32 apps | Microsoft Learn

※　マウスカーソルを合わせて右ボタンメニュー　リンクを新しいタブで開く　を推奨

　の Microsoft 公式ページの、スクロール中央あたりで確認できる。

　文字列表記や枠表記が STATIC、チェックボックスは Windows でおなじみのボタンと同じ BUTTON 同種別なのが特徴的で、ここでは実例に加えていないがラジオボタンも BUTTON の仲間になる。

　後は、使い道や表示自体はそれほど変わる訳ではない EDIT と LISTBOX だが、EDIT の方は主にキーボードで文字列や数値を入力するための Windows おなじみの機能になる。

＜２　初期文字列＞

　表記文字列。EDIT の場合だと初期項目値になる。WindowBuildTrial の実行画面の方でそれぞれ表記されている文字列と見比べてみると解りやすい。なお、標準 API SetWindowText（　または SendMessage。事情は次章で説明予定　）を使ってプログラム側から変更することもできる。

＜３　用途および表記の種別＞

　上記　Ａ．設定値群の

　になるが、Windows の部品群のおなじみな設定値をそれぞれ用意しておいた。

　ファイルパス入力（　フォルダ入力　）の場合のように枠の制限なく延々と入力できるようにする設定が EP、枠までの文字数で数値のみ入力の右詰めが ER、枠までの文字数で文字列全般の左詰めが EL と、概念的によく用いられる例を用意しておいたが、設定値次第で変更できる。

　Microsoft 側が用意している WS_ や SS_ といったパラメータ指定の定数を使って、このようにＣの | を使った or 演算子の組み合わせによるビットフラグ管理式で指定値を作る、というこの慣習的な方式は、後から追加実装されていくことになった拡張 API Direxct X でもこの慣習は同じ、Windows プログラムの特徴になる。

＜４　追加位置と大きさ＞

　Windows が普及する前までの途上期 16 BIt MS-DOS 時代では、機器は性能が低く高額で画面解像度も狭い世界だったこともあって、画面左上を 0, 0 とする X1 Y1 と X2 Y2 とを結ぶ矩形（　くけい　）の概念が主流だったが、Windows からは、Left　Top　Widfh（　ウィドスだが当ブログ筆者はワイドと呼んでいる。幅　）　Height（　ヘイト。高さ　）の概念に整備された。

　Windows の内部仕様では X1 Y1 X2 Y2 の矩形概念も使われている所もあるが、基本的には Left、Top、Width、Height が主流で、４赤枠の４つの数値がその並びになる。

　Left と Top は、（　メインウインドウから見た　）左上を 0, 0 とした何ピクセル目かという概念については X1, Y1 と類似するが、Width と Height はその対象物の横幅と縦幅という概念になり、ここが X2 Y2 と違う所になる。

　各部品は設置後、プログラム側から標準 API SetWindowPos を使うことで、その位置や大きさを変更および表示／非表示も、できるようになっている。

＜５　動作通知認識番号＞

　ここは、ほとんど通常ボタンのためだけにあるような仕様らしく、Microsoft が推奨している方式のためここではとりあえずそれに合わせている。

　ここに設定した HMENU キャストの中の数値が、そのボタンが押された通知の認識番号が WndProc 側で WM_COMMAND 通知で受け取り、処理（　順述　）を追加していく形になる。

　当紹介ではその認識番号を、ウインドウハンドルの生成順と同じ数に合わせてあるが、番号処理の設計の仕方として例えば、ボタン番号の場合は 1000 からを基準とし、順番に 1000、1001、1002 と割り振っていく、といった番号設計の仕方でもよい。

　STATIC 部品にこの HMENU による番号を割り当てても、その STATIC 部品がクリックされてもその割り当て通知は発生しない仕様になっているが、ただし、順述するが Windows の WndProc 的仕様としては、大抵の部品（　そのウインドウハンドル　）は WM_LBUTTONDOWN（　マウス左押下。おうか　）や WM_LBUTTONUP（　マウス左押下後から離された　）メッセージの通知が来る基本仕様になっている。

　そのため例えば、ここでの HMENU による番号割り当ての概念（　WM_COMMAND メッセージ通知　）など無視して、それが文字表示の部品であろうが、キーボード入力項目の部品であろうが、ボタンであろうが、その部品がマウス左クリックされた場合のそのウインドウハンドルの通知処理として、やろうと思えばいくらでも設計することもできる。

－－－－－－－－－－－－－－－－－－－－－－－－

まず CreateWindowEx によって、各部品を追加していくにあたり、それぞれの部品はある一定の動作までは Windows 側で自動でしてくれるようになっている。

BUTTON による通常ボタンの場合は解りやすく、ボタンを押した際のへこみ動作自体は Windows 側が自動的にしてくれて、後はそのボタンが押された際に何をするのかを WM_COMMAND の通知時にその処理をプログラム側で作り込んでいく、というこの構図は解りやすいが、EDIT 部品（　キーボードによる文字列や数字の入力部品　）の場合は少しややこしくなる。

EDIT の場合は、そこにフォーカスがあたっている際（　マウス左クリック等で選択中のその部品のアクティブ状態　）でのキーボード入力動作について、枠内までしか入力できないよう設定、数字しか入力できないよう設定、などにしておくことの条件動作および、左右キー、BackSpace キー、Delete キー等といった、おなじみのキーボード編集操作は、Windows 側が制御してくれる仕組みになっている。

一方で EDIT の場合、設計者がプログラム側で制御しなければならない例としては、文字数制限をより厳密にしたい、つまり枠の大きさ自体を見栄えのために中央並べで６～８文字分ほど入る広さにしてあるのを、そこを３文字以内、４文字以内までしか入力できないようにしたい場合だったり、全文字入力可能の設定から @ や & やスペースといった一定の入力自体をできないようにする場合だったり、数字のみ入力設定から 0 も禁則にしたい等（　これらを更新処理時のエラーチェックによって入力者に直させるのみではなく、最初に禁則文字にしておく親切仕様にもしておきたい場合　）は、プログラム側が WM_KEYDOWN 等でそれぞれその目的に合った禁則処理、または拡張動作等を作り込んでいく必要がある。

ＭＦＣを使う場合の EDIT はマクロ設定である程度は自動制御はしてくれるとはいっても、入力用途として例えば、BackSpace キーや Delete キーを禁則にすることも、あるいはそれらを押すと入力文字を全消去する動作にしたい場合だったり、@ キーを押すと 0 が代替入力されるようにしたい等、プログラム側からいくらでも設計可能な中（　設計者ごとに様々な仕様が目的にされる上で　）、ＭＦＣによる自動化も万能ではなくここは設計者側が自前で設計しなければならないことも多い。

Microsoft 全般の仕様説明の公式ページ Microsoft Learn （　旧 MSDN　）の方でこれまで、多くが具体例や詳細説明などろくにされて来ず、仕様が多すぎる中で各機能・各詳細ごとを説明し切るのは困難なのは解るのだが、それにしても、ＭＦＣで対応している範囲でそれで解る範囲でそれぞれなんとかせよ感ばかり押し通してきた弊害（　＝　ＭＦＣというオブジェクト指向の規律に沿い始めることは、用意されていない外のことを勝手に始めてはならないかのような曖昧な境界・理由のたらい回しが始まり、自分たちで対応しようとせずに新たに用意してもらうまで待ち続けなければならない感、それを探した有無に終始する感ばかり強め合うことを意味　＝　オブジェクト指向の規律を用いた展開側としての拡張対応範囲のあり方の等族義務の手本が間に合っていない意味　）については、用意する側も用意してもらう側も批判されても仕方ない部分になる。

ここで話を進め、ＭＦＣ側での画面構成の方では Tab キーによるフォーカス移動処理およびその順番の設定ができるようになっているが、ＭＦＣを使わずに Tab キーによるフォーカス移動を実装したい場合は、Tab キー処理を完全に自前で作るしかない。

ＭＦＣを一切使っていない今回の WindowBuildTrial および WindowBuild では、その処理も自前で実装しているが、たかが Tab キーのフォーカス移動処理と思いきや、これが Windows プログラムに不慣れな観点からだと、何の事情説明も無しだといきなり急激に敷居が高くなる話になる。

ただし、Tab キーによるフォーカス移動処理の実装を積極的に把握しておくことは、むしろ Windows の根底仕様を知っておく大事な機会といえるため、順番に説明していきたい。

Tab キーによるフォーカス移動処理にも関係することとして、そちらの処理について説明する前に、Windows の画面構成はウインドウハンドル単位で動作しているというその様子を見渡す最良として、当ブログ説明で以後も重要になってくる、Microsoft Visual Studio の標準機能のひとつ、Microsoft Spy++ について、ここで紹介しておきたい。

Microsoft Visual Studio Community 2026 をインストールする際、詳細設定を特に変更していない場合、エクスプローラーから

このフォルダの場所にある spyxx_amd64.exe が Microsoft Spy++ になるため、この exe を右クリックメニュー　コピー　－＞　デスクトップ側右クリック　－＞　ショートカットの貼り付け　を推奨する。

※ spyxxx.exe の方は 32 Bit 版のため間違えないよう注意。32 BIt 版だと以下の説明通りにならないため注意。

この Spy++ は、Visual Studio 側の上部メニュー群　ツール（Ｔ）　Spy++(+)

からでも起動できるようになっているが、上記フォルダ場所の sptxx_amd64.exe を直接実行するのと同じになる。

ショートカットを作っておけば Visual Studio が起動していない状態からでも、気になった時にいつでも Spy++ を起動することができるようになるため、推奨する。

Spy++ を起動すると

このような画面が表示されるが、例えば

もし何も表示されてない場合や、また間違えて　Ｘ　で消して見失った場合などは上部メニュー群　スパイ（Ｓ）　ウィンドウ（Ｗ）

で表示できる。

※　なお　プロセス（Ｐ）スレッド（Ｓ）　については大して注視しなくても、 Windows プログラムの基本を知る上ではウィンドウ（Ｗ）の注視だけで十分のため、そちらについては当ブログでは触れない。

ウィンドウと書かれているその各横の１６進数が、Windows 側からそれぞれ割り当てられたウインドウハンドルで、各ソフトウェア／アプリケーションのメイン画面および、その中でそれぞれ使われている各部品ひとつひとつも、このウインドウハンドルという単位で動作、ウインドウハンドルぞれぞれが Windows の特徴であるマルチタスク仕様（　いったん各独立的に、そこから各ウインドウハンドルと連携しているもの／していないものそれぞれ同時動作　）に沿って各動作している様子が窺える。

その画面にボタン等の部品が設置されている場合、親ウインドウハンドル（　Parent 概念　）に所属する子ウインドウハンドル（　Child 概念　）という階層概念で動作していることが、この Spy++ で確認できる。

※　Microsoft Spy++ は参照しかしていないため、ここでどのような操作をしても Windows のどこかのシステム障害を引き起こすということもないため心配無用。

ここで、Visual Studio 側の WindowBuildTrial プロジェクトで F5 キーを押して画面を表示させるか、またはバッヂビルド後の WindowBuildTrial.exe からその画面を表示させた状態で

まず WindowBuildTrial の画面と、Microsoft Spy++ の画面の両方をこのように、手前側に表示されている状態にする。（　タスクバー側を押すなどで手前側に表示　）

次に Microsoft Spy++ 側の

２の赤丸を押すとこの　ウィンドウの検索　の画面が表示されるが、その前に１の赤丸を押してから２の赤丸を押す。

Microsoft Spy++ は、各画面（　各ソフトウェア／アプリケーション　）が終了されたり起動されたりしても、ウインドウハンドル一覧が最新情報に自動的に再表示される機能が特にないため、新たに起動された画面を対象にしたい場合や、またはいったん閉じて起動し直した画面を対象にする場合、Windows 側の基本仕様として毎回違うウインドウハンドルが割り当て直される特性からも、１の赤丸の最新再表示ボタンを毎度押さなければならない場合が多いことに注意になる。

３矢印のファインダーツールを使うが、これはマウスドラッグ式（　左クリック押しっぱなしで掴む仕様　）になっているため、これを掴んで

このような操作で、WindowBuildTrial のタイトルバーあたりにもっていって、左ドラッグを離すと

このファインダーツール操作によって、対象のウインドウハンドル、キャプション名、クラス名がこのように取得できる。

この状態で　ＯＫ　ボタンを押すと

このように、該当するウインドウハンドルの行にセル検索移動をしてくれる。（　うっかりの最新再表示ボタンの押し忘れが原因で、該当無し無反応になる場合も多いため注意　）

そのツリー展開　＋　を押すと

WindowBuildTrial 内で、Windows 標準 API CreateWindowEx によって画面に追加されていった各部品の関係が、メインウインドウ（　親。Parent　）に所属している各部品群（　子。Child。当例では１５個　）の構造として表示される。

ここに、それぞれ Windows 側に割り当てられたウインドウハンドルと、文字列情報、認識クラス名の３つの情報が一覧的に表示されているが、CreateWindowEx の方での認識クラス名指定の STATIC、EDIT、BUTTON、LISTBOX 等は Windows 側では、頭文字ごとで大文字、後は小文字に置き換えられて情報管理される仕様になっていることが窺える。（　Microsoft Learn では大文字での指定の説明になっているが、static や ListBox という指定の仕方でも認識　）

次に、WindowBuildTrial 画面の、動的項目（　フォーカス対象　）としてのひとつ目となる、文字列情報 'C:\Program Files' 認識クラス名 Edit の項目をセル選択し、その上て右クリックメニューでプロパティをクリックすると

プロパティインスペクター画面が表示され、そのウインドウハンドルについての詳細情報が確認できる。

以下、この各タブ画面を順番に貼っていくが、これら内容はそんなに熱心に見なくても、ざっとでよい。

この Microsoft Spy++ を通して、これら情報群から伝えておきたい Windows 内部仕様のここでの要点は、３つになる。

１．プロパティ画面それぞれに、あれこれ表示されている各情報がこのように表示されているという時点で Windows 標準 API 側でこれら情報の大抵は取得できるようになっている、という解釈でよい。（　この Microsoft Spy++ の構図自体、統合前 32 Bit 時代の３０年前と全く変わっていない　）

２．ウインドウハンドルが一覧的にずらりと並んでいるこの様子から察することができるように、よそのインスタンス（　ソフトウェア／アプリケーション。exe や dll　）から、よそのウインドウハンドルに所属している例えば BUTTON や EDIT 等に対して、ある程度の操作はできることが　１．　から窺える。ただしこれは条件が少しややこしく、専門家でもないここでの当ブログ筆者の問題もあって、できたりできなかったりの話もある。例えばよそのウインドウハンドルの画面事情をあらかじめよく認知していて、その対象を前提に限定していたり、または一定の法則の探知をする作りにしていれば、よその画面のボタンを押したことにする処理を作ったり、よその画面の入力項目などの文字列内容の取得や、またその編集／消去をかける設計などもできる。※　この仕組みに慣れておくとなぜ有利なのかについて、のちほど別章で実例紹介する予定　※

３．ＭＦＣ側での画面構成の内部リソース設定では、Tab キーによるフォーカス移動処理が Windows の標準機能であるかのようにその順番の情報項目が用意されているが、Microsoft Spy++ による詳細情報を見渡してみると、Tab キーによるフォーカス移動処理のための情報項目が見当たらず、ＭＦＣ側のマクロ自動化機能による完結であることが窺える。Windows 標準 API には部品間のフォーカス移動の概念自体は用意されているが、Tab キーによって順番にフォーカス移動をしていくという概念自体は特に用意されていない。入力項目が並んでいる画面でよく見かける、Tab キーによるフォーカス移動という概念自体は広く認知されているからこそ、Window 根底仕様として用意されてそうなその概念が特に用意されていなかったことは、これは当ブログ筆者としても意外だった。

ＭＦＣの関連マクロ（　内部リソース　）を使わずに画面構成をする場合、Tab キーによるフォーカス移動の順番処理が欲しければ自前で作らなければならない。

今回企画 WindowBuildTrial および WindowBuild の方でその部分を自前で作ったが、Ｃや Windows の仕様に不慣れな者から見ると、ここは難易度がやけに高い部分になる。（　だからＭＦＣではこの部分はマクロ自動化仕様にしたのだと思われる。この話にも関係するため今回 Microsoft Spy++ を紹介した。次章でその意味を説明する　）

Tab キーフォーカス移動処理の説明および、Ｃ書式規律の説明等を今回したい所だったが、ブログ字数制限の都合で、次の０４章０２／０２で説明することにした。

今回は、この Microsoft Spy++ についてあとひとつ　メッセージ　関連について紹介しておきたい。

ウインドウハンドル一覧の WindowBuildTrial のメインウインドウの所で右クリックメニュー　メッセージ　を選ぶと

Message 画面が表示されるため、次に上部メニュー群の　メッセージ（Ｍ）　ログオプション（Ｏ）

メッセージオプション　画面が表示されるため、チェックボックスの　親ウインドウ（Ｒ）　子（Ｃ）　のふたつにチェックを入れて　メッセージ　のタブ表示にする。

Windows 内部仕様としてまず、様々な想定動作による通知種別が実に 1195 個、右側のチェックボックス群には、そのウインドウハンドルごとの役割の想定種別もこんなにある。

こうして見渡してみると、 Windows 全体仕様からすれば当ブログ筆者はその１％も把握しているのかどうかが実情だが、ただし膨大な組み合わせがあるという訳ではなく、当ブログ説明においてのメッセージ仕様の紹介もこの内のせいぜい１０個２０個程度に過ぎない、それだけでも Windows プログラムの基本はだいぶ把握することができる。

この全 1195 メッセージ通知設定のままだと、常に通知し続ける大量のメッセージが多すぎて何が起きているのかが全く確認できないため、ここで使い方例としてまず　全てクリア　のボタンを押すと

全ての選択が外れるため、操作が少し大変だがこの状態から、メッセージリストの縦バーを使って、

この画面の、１の赤丸　のスクロールバーのあたりの位置に　WM_KEYDOWN　とその近くに　WM_LBUTTONDOWN　があるため、そのふたつをセル選択する。

セル選択の内容に応じて、チェックボックス側が自動的に変化するが、こちらは特に触らなくてよい。

チェックボックス側のチェックを入れることで、その種別に関係するメッセージが全て選択される仕組みになっているため、間違えて押してしまった場合は　全てクリア　ボタンを押し直せばよい。

ふたつのメッセージを選択して　ＯＫ　を押して

このように、WindowBuildTrial の画面（　ファインダー指定した画面　）と Microsoft Spy++ の画面が手前に表示されている状態で、WindowBuildTrial 側の画面のどこかをマウス左クリックしたり、入力項目の所でキーボードを押したりすると

操作例で、１のテキトーな所を左クリック、次に文字入力をクリックしてフォーカスを移動し、キーボードで　k　e　y　と３文字入力の、その５操作が

このように Message 画面に反映され

そのウインドウハンドルに対するメッセージであることが確認できる。

この情報群が送られてくるのが、メインソース側の WndProc 手続き（　関数。プロシージャ　）で

ウインドウハンドル、メッセージ、付与情報１、付与情報２　の４情報による、どのような場合のどのような通知が来たのかに対し、（　そのメッセージ通知が来ても何もしない場合も含め　）どう動作するかの判定的な分岐処理を行うことになるが、Microsoft Spy++ の Message 画面でその仕組みを確認できるようになっている。

少しややこしいが、Microsoft Spy++ は、誰かが作った exe を解析するものというよりも Windows 側の内部仕様としての構造情報を理解するための説明書のようなものになる。

Message 画面にしても、Windows 側としてはこういう契機にこういうメッセージが exe 側に通達される、という確認はできても、その exe がどのメッセージに対して通知処理を実施しているのか自体は、ここからでは確認できない。（　処理が行われた契機が、何のメッセージの時だったかという、反応を見ながらの手さぐり的な確認ならできる　）

仕様が多すぎたり細かすぎたりで Microsoft Learn の方でその全てをとても説明仕切れないからこその、その説明書代わりに用意されたものといった方が正確になる。

Windows の内部仕様についてもう少し説明したい所だったが、字数制限の都合で Microsoft Spy++ の説明は今回はここまでとする。

WindowBuild の方に視点を戻し、Ｃ視点および Windows API 視点での説明を次の０４章０２／０２の方とし、今回プロジェクトの WindowBuildTrial と WindowBuild の、この違いの概要だけ説明しておきたい。

まず、WindowBuildTrial の方で CreateWindowEx によって各部品群を追加しているこの部分についてだが

内部リソースに何ら縛られることなどない非ＭＦＣだからこそ、この部分をＨＴＭＬ的に外部ファイル化してしまえば良いという改良版が WindowBuild の方になる。

改良版 WindowBuild の方を起動すると、起動時は改良前 WindowBuildTrial と変わらないように見えるが

F2 キーを押すと

最初の画面と少し設定値を替えた、画面切り替えになり、F3 キーを押すと

全然違う構成に、画面切り替えされる。

改良版 WindowBuild の方では、このようにテキストファイルを３個用意してあり、それぞれ

WindowBuild01.txt　※　テキストエディタは　秀丸

WindowBuild02.txt　※　01 から初期値を少し変えただけ

WindowBuild03.txt　※　名簿管理のような例にしてみた

F1 ～ F3 キーを押すことで、これら CSV 形式の画面データを読み込んで画面を即、再構成する動作にしてあるため、そのテキストデータに変更をかけながら F1 ～ F3 を押してすぐに確認することもできる。

こういう形にしておくことで、部品の位置を変更したり項目を追加する際に毎度、Visual Studio でコンパイルし直さなくてもよくなる。

左から順番に、項目１は部品種別、項目２は文字列や初期値、項目３～６は Left Top Width Height、最後の項目７は処理番号になっているが、WindowBuild03.txt については何の作り込みもしていないから全て 0 にしてある。

なお WindowBuild で扱うテキストデータのフォーマットは、ANSI SHIFT JIS（　MS-DOS 時代以来の半角 1 BYTE 全角 2 BYTE 混在の旧マルチバイト式。当ブログ筆者はいまだにこちらを愛用している　）と、近年推奨の UNICODE-16LE （　全 2 BYTE 式　）の、このどちらかに対応している作りにしてある。

※　大抵のテキストエディタはどのフォーマットで保存するかも選べるようになっている。Windows 標準搭載のメモ帳でもフォーマットごとの自動表示や保存別が可能。

今回は最後に、改良版 WindowBuild の方でのプロジェクト名変更（　プロジェクト差し替え　）についても、一応紹介しておく。

Visual Studio の新規プロジェクト作成　Windows デスクトップ　アプリケーション　の方で、今回は WinInput という名称に変更する例とする。

プロジェクトが作られたらこの WinInput プロジェクトの Visual Studio 閉じ、エクスプローラーで WinInput プロジェクトを作ったフォルダのソースファイル群を表示し、

※　当ブログ筆者の場合は C:\FilesVC\ という場所で Visual Studio のプロジェクトデータを管理している

framework.h、Resource.h、WinInput.cpp、WinInput.rc　の４ファイルを削除する。（　今回は framework.h も変更している　）

次に、WindowBuild のソースファイル群の方で

framework.h、ImagePNG.ico、Resource.h、WindowBuild.cpp、WindowBuild.rc　のプログラム側の５ファイルおよび、参照ファイル WindowBuild01 ～ 03.txt の３ファイルを、WindowInput 側のソースファイルフォルダにコピーする。