Windows C/C++ 検証報告プロジェクト AssistKeep ０２／０３ 2026/03/20
※ ここでは、オブジェクト指向の規律および、マイクロソフト独自仕様が濃すぎてもはやＣ／Ｃ＋＋ではないリソース／マクロはできるだけ除外しながら動作確認、正しいかどうかの前段階としての 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 化本格発足となった NT 4.0 以来の Windows API（ 32 Bit 本格化当時の Windows 標準内部仕様 ）の意味が強い。
※ 当ブログの解釈・意図の構築の仕方は、それは当ブログ筆者がたまたま統合前 32 Bit 時代から見渡してきた Microsoft の Windows 標準 API 史的、CRT 史的、UNICODE 対応史的な、ここ３０年のＯＳ内部仕様をざっと見渡しての、統合期 Windows XP 以後の 64 Bit 化以降も進められてきた Microsoft のＣ原点回帰的な概念整理を、ＩＳＯ９０００系善用重視で見渡した上であることを、前章までにその経緯をこれまでひと通り説明してきている。
※ ここでは、外・下・新参側（ よそのこと道義領域外のこと ）に厳しさを向ける以上は（ 合格・高次元・格上／失格・低次元・格下 を等族指導する側を気取る以上は ）、内・上・古参側（ まずは自分たちの次の段階の上同士視点の手本の作り合い ）にはそうなる前の５年前１０年前にその１００倍１０００倍の厳しさが既に問い合われ済み（ ＩＳＯ９０００系善用の年期計画的な選任評議序列敷居改めのためのまずは上同士の上方修正といえる式目整備の原本作りの論述整理・議事録処理体制 ＝ 荀子・韓非子・孫子の兵法の組織論の基本中の基本として、広域情報処理力・領域敷居管理力による構想競争の段階で既に勝負するまでもない優劣差が開いていく一方になる、だからまずは何にしても自分たちの上同士視点の敷居の見直し最優先で危機感・自己等族統制観を常にもてと指摘 ）で間違いないから低次元ないがみ合い（ 低次元化させ合う下の作り合いしかしていないただの性善説放任主義・偽善憎悪・老害浪費の乱立拡散 ＝ 法賊行為・老害愚行 ）を２度と繰り返させない側（ 近代選任評議会観といえる敷居交流規律の手本を示す側 ）で間違いない前提が言うまでもない最低限としている。そもそもその前提になっていない時点で、まずは自分たちにとっての人間性（ 自力信仰性・当事者軸性・痛感性・自己責任性 ）と社会性（ 他力信仰性・主体軸性・教訓性・社会的責任性 ）の領域敷居管理による、自分たちの年期計画的な社訓改め・式目序列規律改め（ まずは上同士の上方修正の原本からのきざみ下方修正的な再細分化と再集約化による旧互換・非互換の統廃合管理。プログラム設計の上達でも基本中の基本 ）の手本の作り合いなど自分たちで全くしてこれなかったのと同じ、よそのこと道義領域外のことをどうのの前の自分たちのその最低限も自分たちでできたことがない、自分たちのその愚かさだらしなさも自分たちで認識できるだけの知能もない教育機関絶対およびオブジェクト指向の規律絶対のただのいいなりの知能障害の集まりの偽善法賊どものような、何もかもをケンカ腰に徹底的に面倒がり合いうやむやに低次元化させ合う下の作り合いを繰り返しているだけの上同士失格の怠慢の顔色のたらい回し合いは、ここでは次世代敷居交流荒らしの旧廃策の対象で当然の上から順番の厳しさ倍増論で言い逃れ無用に踏みにじり合う前提になっている。
今回から、前ページでアップロードした今回議題 AssistKeep プロジェクトのプログラム側の説明をしていきたい。
大した規模でもないが、隅々まで説明しようとすると量は結構あるため、これまでの概要はざっと認知できているという前提で、要点整理的な説明の仕方をしていきたい。
本題に入る前に、０１章冒頭で説明していることの今一度の釘刺しとして、ここでは、それが正しいやり方なのかどうかを巡る前段階の
① そもそも Windows というＯＳは一体どのようなものなのかについて、互いにその把握不足・検証報告不足でないかどうかからをまず確認し合うための、まずはその補（ おぎな ）い合いの段階の敷居交流
② 他の分野の向き合い方の共通点も当然出てくる、どういう場合にどういう所に気を付けなければならないのか、どのような向き合い方をしていくことが結局は次の段階に繋がる上達の近道なのか／遅れを取ってばかりに低次元化させ合う典型に向かわせがちなのか、よそのこと道義領域外のことにとやかくケンカ腰に厳しさを向け合い下を作り合おうとする前に、そのための把握不足・検証報告不足に陥っていないかをまずは相互確認し合うための異環境間の選任評議序列敷居参考的な次世代交流規律といえる見渡し方（ 低次元化防止の旧廃策のための再集約化・再細分化 ＝ 上方修正側と下方修正側／当事者軸側と主体軸側／自己責任側と社会的責任側 の領域敷居管理の論述整理的・議事録処理的な見渡し方 ）を、そこをうやむやにさせ合わない前提を互いに本当に大事にし合うことをしてきたのか／しようとしている前提なのかの上同士視点のあるある話（ ＩＳＯ９０００系善用の手本といえる見渡し方 ）をまずは最優先で確認し合う段階、まずはその論述整理性・議事録処理性の敷居交流に対する規律不足・確認不足を補い合う段階
の、その他力信仰不足を補う発信の場（ 上同士視点の手本といえる次の段階の環境体制更新観・社会的責任更新観・社訓更新観の領域敷居管理の年期計画的な見直しを互いにし合う前提をそもそももてているのか／してきたのかの問い合い ）として当ブログ筆者は、それを主目的にこのアメーバブログアカウント環境および Microsoft Visual Studio Community 2026 環境を場借りさせてもらっている。
そういう意味の交流の場だとする当ブログの用法はアメーバブログ全体の民権言論面の一例に過ぎない、その一例の可否を巡る意見回収的・式目敷居的な最終判定はブログ運営社側がすることなのであって、そこを目先の利害次第にケンカ腰にうやむやに荒らし合い低次元化させ合う下の作り合いしか能がない教育機関絶対およびオブジェクト指向の規律絶対のただのいいなりどもの上同士失格の怠慢の顔色にその可否の全権があるのではない。
当ブログの用途を容認し続けるかどうかは運営社側が決めることで、アカウント停止措置にしたいならすればいいというだけの話、場借りさせてもらっている立場である当ブログ筆者が決める話ではない。
本題に入り、前章 Windows C/C++０５章 AssistKeep で Project_AssistKeep.zip をダウンロードしている前提、Windows 10 / 11 でのその用法を把握している前提、そのプログラムソースファイルを Visual Studio 2026 で確認できる前提、４章 WindowBuild までの経緯（ 非ＭＦＣ事情 ）をざっと把握している前提、で話を進める。
今回議題 AssistKeep プロジェクトは、前回議題 WindowBuild プロジェクトの続きからの 手助けアプリ 意識の展開例ということで、まずは、WindowBuild を元手に AssistKeep 化する過程で生じた想定不足について、いずれも修正規模は小さいがその計４概念箇所の改良点からまず説明していきたい。
内３つは画面側に関連しているため、そちらから説明する。
まず LISTBOX の 赤１ について、横スクロールバーの機能も追加することになったため、その箇所について。
AssistKeep は Microsoft Edge と連携する使い方になることで、横幅を狭くしたが、LISTBOX の方では長いフォルダ名でも確認できるよう、特に履歴側の LISTBOX はフルパス表示だからこそだいぶ横長になる中でも確認できるよう、横スクロールバー機能も追加することになった。
WindowBuild 手続き内で完結させている LISTBOX 部品パラメーターに WS_HSCROLL を追加し
この ListHorizon 手続きを追加し、リスト情報の更新（ 再構築 ）が行われるたびにこの手続きを呼び、横スクロールバー機能に必要な長さ設定がされる仕組みを追加。
なおここで呼ばれている手続き SendMessageW、GetDC、GetTextExtentPoint32W、DeleteDC は全て Windows 標準 API 手続きになる。
HDC 型はデバイスコンテキストハンドルといい、これは Windows プログラムの特徴的な変数型で、概要的には Windows 機能の内部的・詳細的な操作をする際に、それにアクセスするための番地変数と強調の概念変数型になる。
番地管理は 32 Bit コンパイルなら 4 Byte 、64 Bit コンパイルなら 8 Byte 管理というだけの話で、デバイスコンテキストハンドル（ HDC ）も、機械語面から見た性質ではインスタンスハンドル（ HISNTANCE ）や ウインドウハンドル（ HWND ） 等と大差ないといえる。
こうした用途概念ごとの各アクセスハンドル管理（ 番地管理 ）は、機械語内部的な見方からすれば 64 Bit コンパイルなら 8 バイト領域の変数でさえいれば、都度キャストさえすれば別概念ハンドル変数や、__int64 型や WCHAR * 文字列番地型などを使って受け渡しをしても同じことではあるものの、しかしここは０３章でも説明してきた通り、Microsoft がそれぞれの用途概念ごとの変数型を用意してくれていて、コンパイルの方でその互換／非互換の厳格化（ 概念整理の手助け ）が推進されてきたという Windows C / C++ の経緯は、軽視してはならない。
Microsoft が概念ごとに用意してくれている変数型にいったん沿った変数型計画を基本としておいた方が概念整理に結びつくため、例えば何らかの目的で様々な番地管理の互換／非互換に対応する仕様を作る場合などでも、本来のその変数型計画の基本をいったん踏まえる上で、解っている上で汎用化目的で外れた部分もある独自概念の作りにしている、という順序的な概念整理の想定設計を常に疎かにしないようにすると、上達に繋がる。
次の想定不足について、AssistKeep ではボタン部品を利用不可にする概念を用いることにしたのが 赤２ の部分で、その概念を用いた際の Tab キーのフォーカス移動処理でその想定がされていなかったため、WndProc 内の Tab キー処理で判定をひとつ追加することになった。
WndProc 内の、Tab キーが押された所のフォーカス移動の箇所だが、フォーカス移動の対象部品かどうかの判定後（ EDIT か BUTTON か LISTBOX かの頭文字判定後 ）の所に今回の想定不足分を追加、Windows 標準 API の IsWindowEnabled を使い、その部品が現在利用可能状態であるかを取得し、可能状態（ TRUE ）であればその部品ウインドウハンドルにフォーカスを移動、利用不可状態（ FALSE ）なら次の部品の判定、という動作になるよう改善。
次に 赤３ の部分だが、AssistKeep での HWND ボタンの特徴的な動作の実装について、
WinMain 側の GetMessage の方では WM_ 系メッセージ通知は来るはずが、WndProc の方にはなぜか通知されないことで HWND 取得ボタンの、マウス左ボタン押しっぱなし動作等の処理が、Microsoft 見本通りのままにしているとその実装ができなかったため、WinMain 側の GetMessage の所で WndProc 側になぜか通知しようとしない WM_ 系メッセージを判定的に通知するように改善したのが、赤指摘の部分になる。
４章で「この GetMessage の部分は他はそんなに改善することはないと見られる」という説明の仕方をしてしまったが、しかし実現したい仕様によってはこうした「 GetMessage による WM_ 系通知は来ているはずが WndProc にはなぜか通知されない、WndProc に通知させたいメッセージが他にもあった」となったのちのことも考え、その場合に対象メッセージを後で容易に追加できる作りにしておいた。
次に最後の４個目は、外部テキストファイルからの環境情報の取得で、行間を整えるための半角スペースは除外の仕様をうっかり、フォルダパス取得の際に（ ダブルクォーテーション無しの場合に ）半角 Space もあり得ることが考慮されていなかった欠陥を、改善した。
FileCSVRead 手続きでは、CSV 形式のテキストデータを、カンマ１件ごとか（ そうでない場合はリターンコード１件ごと ）の前提によって取得する仕組みにしてあるが、引き数の追加で半角スペースの true / false 管理をする作りにしようと思ったが、今回はカンマ１件ごとでない場合は、主にフォルダパス文字列１件の場合と見なす概念で、その場合は半角スペースの除外はしないという仕組みに改善した。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ここまでが前回分までの想定不足分の改善で、以下、今回実装分の説明に入るが、プログラムの作り自体は前回よりもさらに省略的に概要をざっとで、上達のコツ／注意点中心に進めていきたい。
まず画面側の概念は、前回 WindowBuild のものを基本に、外部テキストデータ AssistKeep01.txt から画面を構成し
７項目の役割番号を優先、つまり情報項目からの想定計画を優先（ データ設計優先 ）で
プログラム側（ 受態側・解釈対応側 ）を想定設計していく、その基本手順でまずは情報側を何度も見直しながら、ひとつひとつの機能を作っていったが、そこは前回議題 WindowBuild で説明した通りになる。
形ができてくることによって、詳細の部分では計画当初は気づかなかった、いくらでも再細分化と再集約化ができる箇所が次々と出てくるのも常で、今回もそこは同じになる。
前回議題 WindowBuild の時に上達のコツとして説明した通り、今回分としての概念整理次第に、定数名、変数名、手続き名も何度も直す今回分の概念名設計の繰り返しの見直しからまずは怠らないよう、できるだけ概念整理と一致した概念名になるよう、まずはそこから何度も直すことを面倒がらないことを、今回も心掛けている。
いったん作ってみることで手続き間・変数間の関連の詳細の形も見えてくるからこそ、当初は想定していなかった再細分化と再集約化ができそうな共通概念が次々に見えてくる各箇所の改善余地を概念整理し直しても、次の改善余地が出てくる繰り返しが常だからこそ、今回分としての計画的な領域管理をしながらの集約化と細分化の繰り返し（ 各概念に対する変数名・変数型・手続き名・手続きの役目が一致しているのかの概念名直しから ）を面倒がらずに積極的に取り組んでいく前提をもつことがまずは重要になる。それを繰り返して「ああ、結局こういうことだったか」の確認を自身で積極的に地道に重ねていくことが結局は上達の近道、どういう場合はどうしていけばいいのかの、前回分・今回分・次回分以降の段階管理（ 上同士視点 ）の見渡し方の今後にも結びつくようになる。
当ブログの 近世日本の身分制社会 の時の、特に最終部２Ｐの １６７ と １６８ ができるまでもそうだったこととして、実際は３倍近くは記述し、何度も概念整理し直した結果としてあの形になったのと同じく、今回の AssistKeep プログラムも実際はこの３倍近くの動作確認をしながらの、今回分としてやっておいた方がよい領域管理としての集約化と細分化が繰り返された結果、この形に落ち着いたに過ぎない、といった所になる。
前章で説明してきたことの念押しとして、まずは定数名・定数値・変数・変数名・変数型・変数値それぞれの存在・役割のまずはデータ側の想定計画の方を優先で何度も見直す前提を常にもつことを忘れてはならない。
データ側のそれぞれの概念・役目は、次第にプログラム側が形作られていく過程で当初想定していた概念と大小の不一致・ズレがあちこちに出てくるのも常だから、まずはデータ側の概念形態（ 定数名・定数値・変数・変数名・変数型・変数値それぞれの存在・役割 ）を見直し、その概念形状との不一致が起きている関連部分は計画性（ 低次元化・弊害化させ合わないためにまずは不一致理由を明確化 ）をもって、大変かも知れなくてもどこかの契機で一斉に直していく段階管理を常に面倒がらない前提をもつ（ まずは情報群想定計画側・データ設計側を優先に、不一致関連も全て直していく前提をもつ。旧廃策の対象のはずの足の引っ張り合いの致命的な原因となる非互換・残骸禍根概念を次回分以降にいつまでも残し続けない次の段階への自分たちの課題をいつまでも面倒がって性善説放任し続けた分だけ自分たちのその足枷の弊害を重くしていく一方の深刻さを常にもつ ）ことが、結局は上達の近道の基本になる。
※ 当初・以前の概念の定義づけとの不一致が起きている、意味不足や概念不足が目立ってきている自分たちが用いる概念名（ 普段からの用語・式目・設備等の用い方の次の段階の互換・非互換に対する再整備・再厳格化・再等族統制化 ）はそのまま、自分たちの方法論の組み立て方（ 自分たちの上同士視点の手本の評議敷居観の作り合い ）の原本の論述整理観・議事録処理観（ 認識の中 ）の見渡し方に直結してくる。改善余地が必要な自分たちのその不一致の弊害部分（ 低次元序列権威化させる部分 ）に対する自分たちの前回分・今回分・次回分の計画的な段階管理・領域管理の再設計・再統制を、自分たちでケンカ腰に徹底的に面倒がり合いなまけ続ける（ ＝ 上同士失格の怠慢の顔色をたらい回し合う下の作り合いでいつまでもうやむやにし続ける ）分だけ、自分たちで後戻りできなくしていく偽善曲解（ 性善説放任主義・偽善憎悪・老害浪費 ）の上塗りが重ねられる一方、次の段階への道から遠のく劣悪環境に向かわる一方なのは、Windows プログラムに限らずの他の分野でも同じ、まさに荀子・韓非子・孫子の兵法の組織論（ 本来の上同士視点 ）の指摘通りの基本中の基本の話に過ぎない。
データ 設計側 ＝ 何が起きているのか の主に入力領域管理側
プログラム設計側 ＝ それにどう反応するのか の主に出力領域管理側
教育機関絶対およびオブジェクト指向の規律絶対のただのいいなりどものように、よそのこと道義領域外のことにケンカ腰にとやかく厳しさを向け合おうとする前の、旧廃策の対象（ 改善余地 ）だらけのはずの自分たちの概念整備不足のままの受態解釈側（ プログラム管理側 ）の不都合を、力関係任せに情報側（ データ管理側 ）に合わせさせ続けようとする偽善曲解のねじ伏せ合いで本来の順番を逆さまにうやむやにし続けたままの自分たちの愚かさだらしなさも自分たちで直せたことがない上同士失格の怠慢の顔色のたらい回し合いを、だから当ブログでは言い逃れ無用に上から順番に踏みにじる前提だといっているのである。
どの分野でも共通点の多いこうした、上同士視点の見渡し方のあるある話（ よそをどうのの前の自分たちの、まずは上同士からの上方修正の規律敷居がそもそもどうなっているのか ）を当ブログ筆者が重視している結果として今回議題 AssistKeep のような紹介もできるようになった、というだけのごく自然な話に過ぎない、逆にそれ無しではこういうこともいつまでもできるようにならないまま、というだけの話に過ぎない。
今回議題 AssistKeep も、今回分としてのある程度の概念整理の繰り返しによって、ある程度の再細分化と再集約化がされた結果として今回の形に落ち着いた、というだけの話でしかない。
本来のその姿（ よそのこと道義領域外のことにケンカ腰に厳しさを向け合おうとする前の、まずは自分たちでしなけばならない自分たちの段階管理・規律敷居に対する改善余地が今どのような状態なのか ）を重視し、自分たちの当初や現段階の想定とどう違ったのか／どう変わっていったのかの自分たちの敷居傾向を自分たちで常に履歴管理（ ＩＳＯ９０００系善用によるまずは自分たちの論述整理観・議事録処理観を構築 ）し続けることを、まずはそこを怠り合わない敷居交流的な向き合い方が、結局は上達の近道だという、その念押の一例が今回議題 AssistKeep に過ぎない。
上記の、定数群の役割番号についての主に WndProc 側のことも追って説明するとし、AssistKeep.cpp 上部の前方手続き宣言群（ 関数・プロシージャ ）から、それぞれがどういった役割のための手続きなのかを、一覧的にざっと説明していく。
前回 WindowBuild プロジェクトでは、外部テキストファイルは読み込みのみだったが、今回は AsistKeep.exe の終了時に環境情報の書き込みもする仕様となったことで、それらのための手続きを追加した。
外部テキストファイルの書き込み関係の手続きとして
① FileCSVOpenWr 書き込みファイルの準備処理
② FileCSVWriteStr 書き込みファイルに、文字列をＣＳＶ式に書き込む
③ FileCSVWriteNum 書き込みファイルに、数値を文字列化してＣＳＶ式に書き込む
を追加。
ここでの FileCSVWriteStr と FileCSVWriteNum のような場合、分けずに引き数違いの２個の FileCSVWrite のオーバーライドの手続きが作られがちだが、前章までに紹介してきたように、概念整理が続けられてきた Windows 標準 API の手続き名の付け方を参考に、オーバーライドはできるだけ避けた、役目の強調化重視の手続き名の作りにしている。
次に
赤１ の WndCategory 系の方で２個追加の
① WndCategoryCmp 画面構成された部品に、その役割番号の部品が使われているかどうかを true / false で返す。
② WndCategorySearchHandle 画面構成された部品に、その役割番号の部品が使われていればそのウインドウハンドルを返す。無ければ nullptr を返す。
ことを目的とした手続きを追加した。
② の注意点として、WindowBuild の時は部品に対する役割番号が６種類しかなくこの概念規模は小さかったが、AssistKeep では１９種類とだいぶ多くなり、部品のウインドウハンドル配列を参照するための配列番号を取得する概念よりも、部品のウインドウハンドルを取得する概念にした方が概念整理面でもだいぶ楽だった（ 後者の概念を今回用いてみたことで、前者の概念の利点があまりないことと、後者の方が Windows 標準 API のハンドル取得概念に近く、内部概念的な前者の手間を隠蔽化できて概念整理的だった ）ことに気づいた。
その説明をしようと、混乱を避けるために今回は直さなかったが、AssistKeep からの延長の紹介を以後する場合は後者の概念で、次回分改善余地とする予定でいる。
赤２ は、LISTBOX の構成関係だが、４個追加の
① ListHirizon 水平バーの最大枠を設定する。
② ListFolderBuildEntry 登録フォルダ情報（ 登録モード ）からリスト作成。
③ ListFolderBuildHistory 名前を付けて画像を保存 で保存された履歴のフルパス情報からのリスト作成。
④ ListFolderMoveEntry 登録フォルダ情報（ 登録モード ）のリストの場合のセル移動時の対象フォルダパス反映処理。
この追加分はそれぞれ別概念の追加の意味が強い、つまり前回分（ WindowBuild ）から今回分（ AssistKeep ）にかけての互換／非互換の概念整理面としての説明はあまりない。
LISTBOX の使われ方はいずれもフォルダ名およびフルパスファイル名ではあるものの、リスト化する情報元の構成も管理方法もそれぞれ違いが多いため、それぞれの役割別な手続き名にしている。
赤３ の追加分の UnionEventPathList 手続きは、部品の役割番号ごとの連動関連をまとめるための手続きになる。
まず、WindowBuild に続いて AssistKeep でも用いることになった、リスト側の選択によってそのフォルダ情報が入力項目側に反映させる動作のような EDIT と LISTBOX （ 文字列入力部品とリスト部品 ）の連動的な作りにしたい場合に、役割番号ごとの連動関係を管轄的にまとめる目的の手続きで、 ここでの Event という意味は主に WndProc のキーイベント時の契機、という意味になる。
最上部の定数群の、部品の役割番号の次に
どのような連動なのかの UnionEventPathList 手続き用の定数群も用意している。
前回議題（ WindowBuild プロジェクトの段階 ）でテキトーなサンプル感があったリストを選択時に入力項目に反映される処理は、今回議題（ AssistKeep プロジェクト ）では重要扱いになるということで、部品間連動の UnionEventPathList 手続きの設置の一環として、テキトー感があった前回箇所ぱ改良しておいた。
WindowBuild 時の役割番号の方と互換化しておいたため、F2 キー（ WindowBuild プロジェクトの時の画面の AssistKeep02.txt ）に切り替えて確認できる。
次に進む。
＜赤４＞
WNDSEARCH_ 系統の定数群は、主にインスタンスハンドル外（ プロジェクト外ウインドウ、AssistKeep.exe 外ウインドウ ）のウインドウハンドル捜索関連の処理用定数になる。
このように、定数による手続き（ 関数・プロシージャ ）側の処理別管理をするのか、それとも定数管理ではなく手続き名（ 関数名・プロシージャ名 ）管理にした方がいいのか、概念整理の問われ所になる。
※ 形ができてくるたびに、こういう所をどうしていくのか、どんな概念名にすればより誤認を少なくできる手続き計画・設計的な定数の使い方になるか、等を面倒がらずに積極的に何度も見直し、自身でその確認を重ねていく前提が、実現範囲を広げる想定設計ができるようになる次の段階への上達にかかってくる。
＜赤５＞
① CheckWndStr 指定したウインドウハンドルに所属する子ウインドウハンドルに、探しているウインドウ名（ キャプション名 ）または部品クラス名のウインドウハンドルが存在しているかを確認する。探す対象は ＜赤４＞ WNDSEARCH_ 系の定数で対応。あれば true を返す。
② CheckNum 指定した文字列が１０進数／１６進数のみかを判定する。そうなら true を返す。
③ CheckNumFull 指定した文字列が１０進数／１６進数のみを前提に、桁指定の最終値か（ ４桁の１０進数なら 9999 か／３桁の１６進数なら FFF か ）を判定する。最終値なら true を返す。
④ CheckFolder 指定した文字列が実在するフォルダかを判定する。あるなら true を返す。
⑤ CheckFullPath 指定した文字列が有効なフルパス（ そのフォルダ構成付き拡張子付きファイル名が実在するか ）を判定する。あるなら true を返す。
⑥ CheckStr 指定したふたつの文字列がピッタリ一致するかを判定する。一致するなら true を返す。
※ 手続き（ 関数。プロシージャ ）を作る際は、補佐／補助のまとまりのある概念単位を目指した方がよい。例えば WinMain 手続きの存在のように、補佐／補助的な役目ではなく主軸的な役目のような中で、if や while 単位が大きな処理になったとしても、主軸的な役目の手続きの場合は無計画（ まず概念名の無整備 ）なむやみな小分けはしない方がよい。今回 AssistKeep では大した規模でないこともあるが、ソースファイルをいたずらに分割してしまうことで見る人を混乱させかねない配慮（ どんな概念整理の経緯でそのプログラムの形に至ったかのを、皆が同じような概念経緯を歩んでいる訳でない中ですぐに解る訳もない。正しいのかどうかの前のその敷居交流をまずは推進していきたいという段階の中で、ソースファイルがいきなり何個も分割されていたら見やすい訳がない配慮 ）から cpp １個で書き切ることにしたこともあって、今回はその例はあまり示せていないが、例えば、大まかに
① Ｃ仕様側／ＡＰＩ仕様側 への補佐・補助概念の性質の強い手続き
② 設計目的（ その企画内の係数や動作に対してなど ）への補佐／補助概念の性質の強い手続き
③ 主軸を小分けしているだけの手続き
等の各概念の軽重分別をしていき、規模が大きくなってきたらこれらごとで他 cpp / h ファイルで分離といった工夫や、① ② ③ それぞれの概念を仕分け（ 再細分化と再集約化を ）していく等、面倒がらずにそういう所も積極的に色々検討していき確認を重ねていく姿勢が上達に結びつく。大まかには 赤５～赤１２ が ① の性質、赤１３が ③ の性質が強い。
※ bool 型変数またはその戻り値の true / false はまずは そうだった場合／そうでなかった場合 というその意義・象形を優先した方がよい。定数名と定数値による概念用意も含めて全般にいえることだが、bool を例えば ＯＫ／ＮＧ の概念に見立てたい場合は、手続き名や変数名に対し、または系統として一貫をもたせる概念整理の強調付けをしておく概念整理の基本を怠ってはならない。例えば、bool を戻り値とする CheckNG という手続きが true を返す場合は「ＮＧである」という自然な意味付けになるような使い方を意識した方がよい。
※ bool に限らず、Ａの概念がＢ概念とＣ概念から見ても意味の不一致は少なかったが、Ｄの概念も関与するようになった時に別の意味や第３第４の意味も出てきてしまった、という、概念間の形ができてきて想定の詳細が具体化してくることで、改めて気づくことも多いその改善余地が次々と出てくるのが常。そこに気づき次第にその関連関係全体を段階管理的に概念名から見直して改善していく前提がとにかく重要になる。Ｄ概念でＡ・Ｂ・Ｃ概念のいずれかを細分化・再集約化しなければならなくなることも常、根底の概念名の見直しから関連全体を大幅に直さなければならなくなることも常な一方、そのひとつひとつを面倒がらずに概念整理を繰り返していくことで、むしろ当初は気づかなかった、機能の対応の幅と快適性を急激に向上させられるきっかけになる。再細分化と再集約化を重ねていくことで改めて「結局、こういうことだったのか」と気づく形で、見渡せていなかったぼやけていた前回分・今回分・次回分の敷居段階（ 互換・非互換の統廃合 ）を次第に自身ではっきりさせられるようになり、上達のコツを掴めるようになっていく。
※ そういう所を延々と後回しし続ける進め方をしてしまうといつまでも上達しないどころか、強引に進めてしまった分だけ概念の不一致がさらなる概念の不一致を生み対応範囲をどんどん狭める一方、後から改善できなくしていく弊害体質が重ねられる一方、次の段階から遠のく一方になる。次々に直面する自身の／自分たちの改善余地にろくに取り組まずに進めてしまう分だけ、概念の不一致を放置し続けながら次の概念の不一致に遭遇するたびに弊害に弊害を重ねる（ 偽善曲解に偽善曲解を重ねる ）弊害の掛け合わせ体質ばかりができあがっていくのみ、次の段階の明るさに全く活きないただ悩んで苦労する暗さのみ、時間と労力の浪費が累積されるのみの最初から全て作り直した方が早い箇所だらけ（ 改善の余地だらけ ）の結果になってしまったことに、そこに後で気づく（ から、本来の手順を面倒がって進めてしまった分だけ次の段階に活きない浪費分がもったいなかった ）こともできるかどうかも怪しい、ありがちな結末（ なお面倒がり続ける姿が、いずれはＡＩで解決できてしまうことしかしていない、誰かが作ったサンプルを流用した方が早い一辺倒の自分たちの弊害負担を押し付け合う下の作り合いしか能がない教育機関絶対およびオブジェクト指向の規律絶対のただのいいなりどもの姿。苦労して悩んだ時間と労力が何ら活きることなどない淘汰側の姿 ）に向かうばかりになる。
× お前に我々（ 世の中の正しさ ）の何を解っているというんだ！
〇 概念間の意義・象形が不一致だらけ、改善余地だらけ丸出しの概念名（ 言葉や用語や式目など ）の低次元な用い方（ ただの偽善挑発 ＝ ただの性善説放任主義・偽善憎悪・老害浪費の押し付け合い ＝ 上同士失格の怠慢の顔色のたらい回し合い ）しかしていない時点で前回分・今回分・次回分以降という段階管理の原本の論述整理性・議事録処理性の見渡し方がそもそもできていないも同然の自分たちのだらしない姿勢をまず年期計画的・選任評議序列敷居的に改めることから始めたらどうか！
＜赤６＞
① StrNumZero 指定した数値を文字列化する。指定した桁数分に 0 を付与する。例として指定の数値が 123 だった場合に 5 桁指定をした場合は L"00123" という文字列を作る。
② StrFolder ※ Windows 10 用までの概念。Windows 11 では使われなくなったらしい概念のウインドウ部品を捜索する手続きのため廃止予定 ※ 名前を付けて保存 画面に内在している表示時フォルダ情報元の文字列からフォルダ文字列部分を編集的に切り取る取得をする。
③ StrFileExtension 拡張子付きファイル名文字列から、拡張子部分を取り除いたファイル名文字列を取得する、またはファイル名部分を取り除いた拡張子文字列を取得する。
＜赤７＞
① AllocListStrInitFile 外部環境テキストファイル（ AssistKeepEnv.txt ）から登録フォルダ文字列情報を全件取得し、その２次元文字列配列を構成する。
② AllocListStrAdd ２次元文字列配列（ 文字列リスト：登録フォルダまたは履歴フルパス ）に、指定した件数目に文字列を１件追加する。
③ AllocListStrDel ２次元文字列配列（ 文字列リスト：登録フォルダまたは履歴フルパス ）から、指定した件数目の文字列を１件削除する。
④ AllocListStrEnd ２次元文字列配列（ 文字列リスト：登録フォルダまたは履歴フルパス ）の使用を終了／メモリ解放する。
⑤ AllocListStrSearch ２次元文字列配列（ 文字列リスト：登録フォルダまたは履歴フルパス ）の中に、全く同じ文字列情報がリスト内に既に存在しているかどうかを確認する。登録済みの同情報かどうかを確認するための手続き。
＜赤８＞
AccumScreenToWindow Windows 全体座標から Screen（ クライアント ） 座標を算出する。Mircosoft Edge 側のポップアップメニューを表示させるために Windows 標準 API の SendMessageW を使って呼び出す際、LPARAM に Edge 側のウインドウ内座標（ クライアント座標 ）を指定しなければならないための、その算出用の手続き。
＜赤９＞
① TimeLimitStart Windows 標準 API の timeGetTime （ Winmm.dll ）手続きの概念名化のための手続き。当 AssistKeep では主に、他インスタンス間（ 他 exe 間 ）のタイムアウトを計るための開始時間の取得を目的にしている。
② TimeLimitCounter TimeLimitStart で取得した計測開始時間を基点に、指定値のタイムリミット時間内かどうかを確認する。false が戻った場合はタイムリミット終了つまりタイムアウトを意味する。
※ 自インスタンス内にしても他インスタンス間にしても Windows プログラムの基本となっている GetMessage（ WndProc ）による各メッセージ通知およびそれを契機とする各動作は、例えば（ HOOK でない通常の ）マウス入力やキー入力関連のメッセージなら即反応的で快適だが、遅延がやけに目立つ（ GetMessage の応答がかなり遅い ）メッセージも多い。例えば Edge 側のポップアップメニュー画面を表示させる契機（ SendMessageW ）を、他インスタンス（ AssistKeep ）から投げかけた場合、ポップアップメニュー画面がすぐに表示される時もあれば、少しモタついて表示される場合も多い。常に多くのタスクを連動的に管理しているのが特徴である Windows 側のマルチタスク管理の都合で、たまに５秒以上かかる場合があったり、確率は低いが Windows 側の何らかの都合で失敗・無効扱いになる場合もたまにある。ポップアップメニュー画面を表示させて 名前を付けて画像を保存 画面を表示させる動作は、通常のマウス操作での呼び出しの際でも、Windows 側のストレージ（ ハードディスクやＳＳＤやＵＳＢメモリなどの ）フォルダ／ファイルアクセスのためのリソースの再読み込みの内部的な都合などで 名前を付けて保存 画面が表示されるまでにたまに何秒もかかることもある等、高性能ＰＣだったとしても Windows ではよく起きる現象になる。Windows 標準 API は同インスタンス内のウインドウハンドル間なら様々な操作補佐の用意がされているが、他インスタンス間のウインドウハンドル間のやりとりについてはセキュリティの問題もあって、その操作補佐は Microsoft は意図的に限定しているものが多い。他インスタンスのウインドウハンドルに対する契機の投げかけもにしても、他インスタンスのウインドウハンドルが今どんな状態なのかを把握する手段も、セキュリティの問題もあって制限が多く、Microsoft Learn の方でもその詳細は大半は書かれていないため、どんな詳細仕様になっているのかを Windows の傾向から予想するしかないものが多い。他インスタンス間の操作は、契機を投げかけた後に（ そもそも他インスタンスからのその契機の投げかけが有効なのかどうか、そもそも Microsoft の容認範囲のものなのかの確認自体が難しいものも多い ）その反応を確認するための同期（ 他スレッド間・他マルチタスク間で非同期的に処理されていく間柄での同期 ）が難しく、他インスタンスへの投げかけがいつ反応するのか、あるいは失敗／無効扱いになってしまったのかも解らない中で、限定的な確認しかできない他インスタンス側（ AssistKeep 側 ）がその反応を待ち続ける訳にもいかないという、失敗／無効時のデッドロック対策も含めて、タイムアウトによる各中断処理（ 使い方としては、処理の特性ごとに１秒～５秒くらいをタイムアウト時間と見立て、投げかけてからその想定動作を確認できなければ、やり直し状態にする ）を用意することになったのが、この TimeLimitStart と TimeLimitCounter になる。
＜赤１０＞
FolderSearchFileNumber 指定したフォルダに、指定している桁数の数字のみのファイル名があるかどうかを確認し、１個以上あった場合はその中の一番大きな数字ファイル名に＋１した文字列（ 数字のみファイル名 ）と true を返す。＋１できない最大値が存在する場合、例えば桁数３の指定の場合に 999 というファイル名が存在している場合はそのエラーを知らせるメッセージボックスを表示して false を返す。桁指定の数字のみファイル名が１個もなかった場合、例えば桁指定が 4 の場合は 0000 という文字列（ 数字のみファイル名 ）と true を返す。
＜赤１１＞
IMEOff 他ウインドウのＩＭＥを半角モードに設定する。
※ Windows 10 / 11 の Microsoft Edge では近年、Copilot という対話式のＡＩ仕様が追加されることになったが、そちらも含めて Microsoft Edge 側のＩＭＥモードが全角のままになっている状態で AssistKeep による Edge 側の操作を行おうとすると、ＩＭＥ全角機能と Edge 側との分断現象が起きてしまい、Windows 画面左上に荒れるような表示がされてしまう。AssistKeep の方から Edge 側をただＩＭＥをオフ（ 半角 ）に戻すだけなのは大した支障でもないと判断し、AssistKeep から名前を付けて保存画面を呼び出す際に、常にオフにする動作をしている。
＜赤１２＞
EndFileEnv F キーによる画面切り替えも含める AssistKeep の終了時の、AssistKeepEnv.txt への環境情報の書き込みをする。環境情報は、フォルダ初期位置、AssistKeep 画面の座標記憶、保存の数字ファイル名の桁数、登録最大数、履歴表示数、登録フォルダ。
＜赤１３＞
① CallPopup Microsoft Edge の ポップアップメニュー を呼び出す。
② CallDialogName ポップアップニュー または ウインドウ上部メニュー から 名前を付けて保存 画面を呼び出す。
③ CallDialogNameSearch 名前を付けて保存 画面が表示されているかを現在の Windows 内の全ウインドウハンドルを１周して確認する。
④ CallDialogNameFolderToFile 名前を付けて保存 画面（ が表示されている前提 ）の入力項目を使って AssistKeep 側が指定する保存先フォルダにフォルダ場所を移動し、名前を付けて保存 画面の入力項目に FolderSearchFileNumber で取得したファイル名に差し替える。
⑤ CallDialogNameEnter 名前を付けて保存 画面（ が表示されている前提 ）の 保存(S)ボタン を押す契機を投げ、保存されたファイルを AssistKeep 側の履歴リストに追加する。
⑥ DialogNameWndSearch 主に 名前を付けて保存 画面に設置されている入力項目（ EDIT ）や保存(S)ボタン（ BUTTON ）等を階層捜索し、そのウインドウハンドルを取得する。Windows 標準 API の FindWindoExW と似ているが、当ブログ筆者の目的通りの階層捜索をしてくれるのかよく解らなかったため自前で作ることにした。今回は 名前を付けて保存 画面に対しての階層部品捜索を目的にしているが、ダイアログ的な画面（ おなじみの入力項目やボタンなどで構成されている画面。当ブログの非ＭＦＣ画面構成的、ＭＦＣ画面構成的／ドットＮＥＴ画面構成的な画面 ）であれば概念的にはどの画面の階層部品捜索にも対応している。
⑦ DialogNameWndSearchFolder ※ Windows 10 まで。廃止予定 ※ 名前を付けて保存 画面に、呼び出し時のフォルダ情報が内在していた場合はそこからフォルダ情報を取得する。
※ 今回議題の AssistKeep は、当初の想定では Microsoft Edge だけでなく他にも メモ帳 などの 名前を付けて保存 を呼び出すアプリに対しての 無変換キー ＋ Shift キー による自動フォルダ移動・自動数字ファイル名保存 にも対応しようと CallDialog 系手続きを少し小分け化してみたものの、各 Windows アプリごとで規格的な一貫が思った以上に無かったことで、そちらの対応については今回は断念することになった。（ そのいくらかの残骸をあえて残している ）まず、名前を付けて保存 を呼び出す各アプリは、メモ帳のように１画面１プロジェクト単位式のものもあれば、ＭＤＩ式（ Microsft Spy++ のような、ベースウインドウ内に複数の種別ウインドウ／プロジェクト単位ウインドウを表示させる形式 ）のものもあり、それぞれ画面構成の仕方が少し違うだけでも 名前を付けて保存 画面を表示させる操作の自動化において、その操作契機それぞれに規格的な一貫性が無く、さらに Wndows 11 になると、名前を付けて保存 画面を表示させる合間の新概念として、保存形式種別メニューの表示が挟まれたその先に 名前を付けて保存 画面を表示するという Windows 10 までには無かった表示順の推進も顕著になっている。 名前を付けて保存 画面を表示させるまでの概念が Windows 11 と、それ以前の Window 10 / 7 / XP 時代とあまり変わっていなければ、画面の特徴ごとにある程度は対応の一定の自動化も絞り込めたかも知れない。当初は 名前を付けて保存 画面が表示された後から自動フォルダ移動および数字ファイル名の自動化をキー実行する機能も試していたが、すんなり動くものもあればそうでないものも多く、用検討事項が多すぎてかなり時間がかかりそうだったため、今回は Microsoft Edge 用のみの対応ということでいったん区切ることにした。
ブログ機能の字数制限の都合で今回はここまで、用意した手続きのざっとの概要のみになる。
次回も上達のコツを伝えることを主目的に AssistKeep の各プログラム部分の要点に触れつつ、あるある話な説明を続ける。