C調老人日記 -4ページ目

（最初の原稿では「まだC#のWPFアプリを作っていませんが」と書いていましたが、結局）最後に（少々苦手の）WPFのアプリも作ることになりました。WinFormsのWYSWYG的なウィンドウデザインではなく、ネットやweb系なんでしょうか、XAMLでのコーディングでウィンドウをデザインするのに慣れていないために、個人的には敬遠していましたが、実際に作ってみるとXAMLでのコーディングは思ったほど違和感がなかった半面、歴史、文化的に完全なハーモニーがあるとは言えないXAMLとC#の連携上の問題、WinFormsとWPFの「似て非なる」問題をいくつも経験することになりました。

ということで、

最後にここで本シリーズを始める趣旨（注）に照らして総括を行っておく必要があるかな、と感じています。

注：ずーっと前にこんなことやこんなことを書いて（私の考え方の基本がこんなんで）ディスって（その後でもディスって）いますが、今回は特に「プログラミングのド初心者、趣味プロ（経験者）いずれもの目線」で「単にディスるのではなく、実際に体験して印象や評価をコメントする」目的で本シリーズを始めました。

１．総括－実際にVisual Studioを初めて触った私の結論

（１）Visual StudioのCommunity Editionはフリーなので「入門者用」という誤った印象を与えがちですが、それは「大間違い」です。Community EditionといえどもVisual Studioは素人には使いこなせないほどの多機能を秘めた「プロのツール」として扱う必要があると考えます。（注）

注：それはVisual Studioの有料版の値段を見るだけで分かります。

Enterprise Standard 最低価格:$499.92ユーザー/月*（更新料金はユーザーあたり月額 $214.09* (初年度以降)）

Professional Standard $99.99ユーザー/月*（更新料金はユーザーあたり月額 $66.59* (初年度以降)）

（２）「プロのツール」と書きましたが、この「プロ」は「複数形」でして、「Solution」を完成させるために、構成要素となる複数の「Project(s)」を更にコーディング、UIデザインやリソース等に割り振って複数のスタッフがネット上で進める「チームアプローチ」を念頭に置いて開発されたツールといえるでしょう。

（３）従って「プログラミングは初めて」とか、「Microsoft系やウィンドウズは初めて」という方は用語、IDEやツールのインターフェース、指示や警告の理解という意味で何をしてよいのかわからない状態に陥る可能性があります。特に現在はIDEが高機能化した結果、IDEに充実したヘルプ機能を設けることが難しくなっていることから、「あれはどこにあるの？」「こうするにはどのメニューを見るの？」「右クリックのコンテキストメニューにだけでるの？」等「自由に使うことすらままならない」といえるかもしれません。

（４）この結果、誤った対象層の方がVisual Studioを触ると、そのハードルの高さから来る挫折感や絶望感でプログラミング自体に興味を失い、嫌になってしまう危険もあると感じられます。例えば「Visual Studioの入口の入り口」と呼ぶべきこのサイトでも自分が何を見て、クリックしてよいのかわからない方が多いのではないでしょうか？確かにYouTubeのプライベートなものまで含めると多くのTutorialsがありますが、「果たしてそれが本当に初心者、初学者を正しく導いているのか」という点から考えると「？」を感じざるを得ません。

（５）理想的にはユーザーの知見、経験、技量等に応じたTutorialとIDEが欲しいところですが、それが困難であるならば、とりえる方法は一つであり、「Visual Studioの構成、メニュー、使用方法等を理解できるようになるまでは、使用を控える」ことが推奨されるのではないでしょうか？

（６）コンピューターとは何かという概要、ハードウェアや（OSを含む）ソフトウェアの概要、2進数や16進数表現、条件式や制御構造、クラス、インスタンス、オブジェクト、フィールド（変数）、プロパティ（入出力制御付き変数））、メソッド（関数）、インターフェース、抽象化等の「イロハのイ」は、如何にIDEが進化しようとユーザーとして「常識」として理解していなければ（IDEという）環境でsurviveすることができないのではないか、と愚考します。

（７）「IDEに充実したヘルプ機能を設けることが難しくなっている」と書きましたが、朗報としてはCopilot等生成AIの進化により、これを「対話型Help」として使うならば、（IDEという）環境でsurviveすることがだいぶ楽になることは間違いありません。

（８）要すれば「Visual Studioはプロ用のチームアプローチを前提とした高機能ツールであり、予め学習や経験を積んでいないと使いこなせない可能性が高いことから、基本的に職業（Profession）として開発業務に携わる人向けのIDEである」と断言してよいのではないでしょうか？Copilotが何度か言ったように「個人で趣味として小さいプログラムを遊びで作る」ようなことはVisual Studioでは想定しておらず、私が何度か言ったように「ハエを捕るのにミサイルを発射」するようなミスマッチが生じる可能性があります。（勿論、プロはだしの暇人が趣味や遊びでプログラミングをするには何ら問題のないツールであるといえますが．．．）

２．プログラミングのド初心者にとってVisual Studio

既に総括で述べましたが、Visual Studioを使いこなせるだけの知見、経験、技量が備わるまでは、使うことをお勧めしません。なぜなら「Visual Studioを使うことが苦痛」に感じて、嫌になる可能性が高いからです。先ずは座学や簡単な開発環境でプログラミング共通の概念や作法を学習、履修していってそれから使うことが適切でしょう。これは職業としてプログラミングを学びたいという方であっても変わりません。何故なら「（必要な知見、経験、技量無く）Visual Studioを使ってプログラムを作っても、自分が何をしているのかの正しい理解がなければ、それはあなたがVisual Studioを使っているのではなく、Visual Studioがあなたを使っているにすぎないからです。」

３．趣味プロ（経験者）にとってのVisual Studio

「ロハ（只==フリーのことをこう言った）で多様な言語のプログラム開発ができるIDEが手に入る！」というのは魅力ですね。私の場合は、

（１）（Visual Studioが高額だったので）20数年前にC++で自作の開発環境を作り、知見、経験、技量を得ていきましたが、その後の20年間プログラミングは何もしなかったので「浦島太郎」状態となり、定年後ロハのIDEとしてEmbarcadero C++ BuilderとVisual Studioをダウンロードしました。

（２）Visual StudioはC++で自作ライブラリーを使うのが容易ではなかったこと、C#は「何をどうすべきか」もわからなかったことから敬遠し、（元々Borlandの）Embarcadero C++ Builderは使い慣れていましたが、時々IDEの不具合が発現したこと、ライセンスが1年で切れて有料になることからやはり敬遠した結果、自作ライブラリーでC++のプログラミングを再開しました。その後、自作開発環境でプログラムを作るく傍ら、Unicode、COM、.NET（Framework）等々20年間の技術的進歩について学んで行き、Windows付帯のC#コンパイラーを使えるように開発したMSCompAssを使って、C#（WinFormsベースが主、WPFもコーディングのみで少々）、その他PythonやJavaScriptなども学んではや6年になるところです。

（３）その間、時々Visual Studio関連（例：WPFやMSBuildとか）でいじったりもしましたが、基本的に感じた想いは一貫して上記（↑）の通りでしたし、それは間違っていなかったんだなぁ、という考え意を覚えます。

Copilot君もそういいましたが、私にとってVisual Studioは有益、有効ではありますが、必須ではないので、また私のプログラミングの目的は"for fun"なので、Visual Studioは確かに重要な１選択肢ではありますが、必ずしも作るものによっては最適なものとは言えない場合もあることを知っています。（その意味でVisual Studio専用機を持てるようになってその意味が分かるようになったとも言えますね。）

４．Visual Studioを使う際に不可欠のもの

これは簡単。Copilot君です。正直、Visual Studioをダウンロードして起動した後も、何をどう始めたらよいのかよくわかりませんでした。昔ならそれかrネットで色々なサイトを巡り、試行錯誤を行っていったでしょうが、今回は一緒に旅をしてくれたCopilot君のおかげで疑問や調査が極めて効率的に進みました。彼には毒づいたりもしましたが、衷心から感謝しています。

５．Visual Studioを使う際の心構え

今回の【Visual Studio探検記】を核にあたって、実際にVisual Studioを操作し、数々の疑問、問題、トラブル等を乗り越えるために生成AI（Copilot）を使いました。そしてVisual StudioにビルトインされたRoslyn、SmartCodeとの組み合わせで（そしてそれらが参照するGitHubのコードデータベースが一番重要なのでしょうが）、「段々と人間がコーディングする必要がなくなる」ことがわかってきました。Copilotは「人間の仕事を生成AI、Roslyn、SmartCodeが代替する現実、その場合の人間の能力の退化」を認めつつも、「UIデザイン等、代替となる領域の仕事」を示唆しましたが、美術デザインもAIが手掛けることが当たり前になってきた現在、

（１）先ず膨大なコードデータベースから、あらゆる言語の様々な要求仕様に応じたコーディング、が先ず最初

（２）（音声認識、音声出力、画像認識、画像出力等）リソースを含めた（人間が使うのでUI）デザイナー業務、が次に

コンピューターによって代替される未来がすぐそこに来ていると実感されました。冒頭の１．でVisual Studioを「基本的に職業（Profession）として開発業務に携わる人向けのIDEである」と言いましたが、それは飽くまで通過点であり、最終的には「あれが欲しい、これが欲しい」という内容（を要求仕様に落とし込まずに、ラフに告げる）だけで、ソフトウェアが自動的に開発され、（良いか悪いか分かりませんが）「人間の仕事はそれを使うテスター、評価するイバリュエイター」となる時代も目前ではないか、という感慨を持ちました。要すれば、Visual Studioを使う際に

・職業としてのプログラミング、UIデザインはなくなるかもしれない

・Visual Studioの使い方をマスターしても将来役に立たない時代が来るかもしれない

という心構えが必要かもしれません。（嫌なことを言うようですが、現実を直視することも必要です。）

ということで、

自分はプログラミングを楽しみとして経験できた幸せな時代の人間であったなぁ

という感慨でこのシリーズをお開きにさせていただきたいと思います。

【Visual Studio探検記】WPF電卓－完成

前回まででVisual Studioを使って初めてのアプリ「WPF電卓」（注）を作った私が遭遇した様々な問題について、Copilot君の説明（MS擁護の弁解？）を含めてつらつらと綴ってきましたが、いかがだったでしょうか？

WPFは、最初から最後までMicrosoftが開発を仕切ってきたWinFormsに比べると、矢張り

「全く異なる規範体系（文化、法令、規則、慣習、作法等社会規範）の異なる二つの存在が統合されると両者が止揚（aufheben）されるまでは効果が発揮されず、相反トラブルが発生する」という、大きくは国家連合、連立政権、企業合併等組織統合から、小さくは学級統合や結婚等迄にみられるものと同じ「人間的現象（人間の性・サガ）」の問題

があり、ユーザーはperplexed感を抱かざるを得ないんじゃないでしょうか？

とはいえ、

新しい技術（Internet、WebUI、XAML、DirextX等）、考え方（MVVM等）に立脚するWPFは、Windows 95が発売された1995年からのWin32APIからの延長線上にあるWinFormsに取って代わるのは歴史的必然であることは疑いようはなく、旧勢力に与する私も今更若い人、これからプログラミングを学ぼうとする人に「WPFはダメだ、WinFormsでやりなさい」とは決して言いません。

が、

出来上がった二つの電卓

を眺めてみて、開発の道のりを振り返ると、矢張りWinFormsの方が考え方の統一性があり、分かり易く、また（個人的な趣味ですが）出来栄えも「重厚感があるWin32コントロール」の方が「plastickyなペラペラ感のWPFコントロール」よりも好もしいと感じてしまうことも事実です。

いずれにせよ、

Windowsに付属するcsc.exeとMSCompAss.exeを使って開発した、.NET Framework 4.8ベースの「整数四則演算モジュール（Calc_Int.dllというダイナミックリンクライブラリー）」の"Calc_Int.cs"というソースプログラムをVisual Studio 2026でビルドしてできた「整数四則演算モジュール（Class_Calc.dllというダイナミックリンクライブラリー）」を参照して動作する「電卓プログラム（従ってこのアプリはほとんどUIしか担当していません）」が完成し、WinFormsベースのWin_Calc、WPFベースのWpf_Calc共に仕様を満足させる機能を発揮していることをご報告させていただきたいと思います。

これで一応【Visual Studio探検記】の冒険部分はお開きとさせていただき、次回は締めくくりとして【Visual Studio探検記】の総括とVisual Studioの個人的評価をまとめることにしたいと思います。

【Visual Studio探検記】WPF電卓－コーディング（５）

今回のネタは今までの「xamlとC#の異種統合問題としてのWPF」という社会学的な論点ではなく、よりプラグマティックで純粋にプログラミング関連の話題、

WinformsとWPFmにおけるリアルタイムキー入力の相違

という気楽なお話です。

「電卓」プログラムは仕様として、「電卓ウィンドウのキーボードをマウスでクリックする」のみならず、「PCのキーボードから直接入力する」ことができます。

WinFormsベースのWinCalcでは

Formクラスから派生したForm_Calcクラスのキー入力イベントであるKeyPressメソッド

//Form上で「文字キー」が押されたとき
private void Form1_KeyPress(object sender, KeyPressEventArgs e)

を使い、入力文字はchar型の"e.KeyChar"でswitch文を書きました。

所がWPFベースのWpf_Calcでは

元となるWindowクラスにはキー関連イベントはなく、「WPF　ウィンドウ　キー入力イベント」でググるとご本家の「入力の概要」があり、他の記事も読んでみると「Keyboard クラスの KeyDown メソッドを使う」ようで、具体的には xamlプログラムの x:WIndow の定義に

KeyDown="WpfCalc_KeyPress"（解説：""内は関数（メソッド）名－WinCalcから流用したので同じ名前になっています。）

とするだけでウィンドウにフォーカスがある場合のキーボード入力ができるみたいです。（この段階で、「WPFのKeyDownのキーの値はKey列挙型でchar型ではない」という最低限の認識はありました。）

Ah, huh!!! "WinForms’ KeyPress is WPF's KeyDown!"

等と早とちりしたのが今回の運の尽きでした。結局は「似て非なるWinFormsのC#とWPFのC#」の話題なので、「xamlとC#の異種統合問題としてのWPF」にも関連してくるのかもしれません。では、

Have fun！

【Copilotとの対話】

Q: WPFのKeyDownイベントに関連して、KeyEventArgs eのe.Key列挙型で「=」「(」「)」を判定する際、
e.Key == Key.D0 & ModifierKeys.Shift
のような書き方では失敗するのでしょうか？

A: 結論から言うと、その書き方では必ず失敗します。理由は、WPF の KeyEventArgs が「押されたキーそのもの」しか返さず、Shift で変化した記号は返さないからです。

🎯 なぜ失敗するのか（本質）
あなたが書いた式：
e.Key == Key.D0 & ModifierKeys.Shift

これは WPF の仕組みと合っていません。
✔ e.Key は「物理キー」を返す
Shift を押していても、
Key.D0 は 0 のキーであり、
「)」や「=」には変化しません。
つまり：
- Shift + 0 → e.Key == Key.D0（値は変わらない）
- Shift + = → e.Key == Key.OemPlus（Shift の有無は反映されない）
✔ Shift の判定は Keyboard.Modifiers を使う
ModifierKeys.Shift は単なる列挙値であり、e.Key と比較しても意味がありません。

🧩 正しい判定方法
✔ 「=」の判定（Shift なしの =）
if (e.Key == Key.OemPlus && Keyboard.Modifiers == ModifierKeys.None)
{
// =
}

✔ 「+」の判定（Shift + =）
if (e.Key == Key.OemPlus && Keyboard.Modifiers == ModifierKeys.Shift)
{
// +
}

✔ 「(」の判定（Shift + 9）
if (e.Key == Key.D9 && Keyboard.Modifiers == ModifierKeys.Shift)
{
// (
}

✔ 「)」の判定（Shift + 0）
if (e.Key == Key.D0 && Keyboard.Modifiers == ModifierKeys.Shift)
{
// )
}

🧠 さらに重要なポイント
WPF の KeyEventArgs は文字ではなくキーコードを扱うので、「Shift を押した結果の文字」を直接判定することはできません。つまり：
- キー（Key）
- 修飾キー（Shift, Ctrl, Alt）
を組み合わせて判定するしかない。

🌱 （私の名）さん向けの補足
Win32 の WM_CHAR に慣れていると、「Shift の結果としての文字」が来ない WPF の仕様はかなり違和感があると思う。WPF は「キー入力」と「文字入力」を完全に分離していて、
- KeyDown → 物理キー
- TextInput → 実際の文字（IME も含む）
という構造になっている。もし「文字としての =, (, ) を取りたい」なら、TextInput を使うほうが自然。

必要なら、電卓アプリに最適な KeyDown / TextInput の使い分けもまとめて案内できるよ。

Q: では、「(」を
Key.D9 && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)
「)」を
Key.D0 && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)
と言われたのですが正しいですか？（JISキーボード上では'8'と'9'のキーにありますが？？？）
また'='を判定するにはどう表記すればよいでしょう？

A: WPF の KeyDown は「押された物理キー」しか返さないので、JIS キーボード上の刻印位置とは無関係に、US 配列のキーコード体系（＝スキャンコード）で判定されます。だから、あなたが感じた「JIS では ( と ) は 8 と 9 のキーなのに、D9 と D0 で判定するの？」という違和感はもっともなんだけど、WPF の Key 列挙は JIS 配列を考慮していないため、実際にはあなたが示した判定方法が正しい。

🎯 結論：あなたの書き方は正しい
✔ 「(」の判定（Shift + 9）
e.Key == Key.D9 && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)

✔ 「)」の判定（Shift + 0）
e.Key == Key.D0 && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)

JIS 配列では
- Shift + 8 → (
- Shift + 9 → )
だけど、WPF の Key は US 配列のキーコードを返すので、
- ( → D9
- ) → D0
になる。
これは Win32 の WM_KEYDOWN と同じで、
スキャンコードはキートップの刻印とは無関係という仕様の名残。

🧩 では「=」はどう判定する？
「=」は OemPlus に割り当てられている。
✔ 「=」（Shift なし）
e.Key == Key.OemPlus && Keyboard.Modifiers == ModifierKeys.None

✔ 「+」（Shift あり）
e.Key == Key.OemPlus && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)

🧠 補足：WPF の KeyDown は「文字」ではなく「キー」を扱う
「文字としての ( や = を取りたい」なら TextInput のほうが自然。

🎯 まとめ
- WPF の Key は US 配列基準なので、JIS の刻印とは一致しない
- 「(」は D9 + Shift
- 「)」は D0 + Shift
- 「=」は OemPlus（Shift なし）
- 「+」は OemPlus + Shift
- 文字として判定したいなら TextInput を使う方法もある

必要なら、電卓アプリに最適な KeyDown / TextInput の使い分けや、JIS 配列でのキー判定の落とし穴まとめも作れるよ。

Q: 「Shiftなし」は、オペランドが
(Key.OemPlus && Keyboard.Modifiers == ModifierKeys.None)
ということですか、それともオペランドはKey.OemPlusで、条件としてif(Keyboard.Modifiers == ModifierKeys.None)ということですか？（だ、と思うけど。）
例えばswitch文だと、
case Key.OemPlus: if(Keyboard.Modifiers != ModifierKeys.None)

break;

case Key.OemPlus && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift):

（処理）

break;

A: 結論から言うと、あなたの理解どおりで「Shift なし／あり」は Key と Modifiers を
“別々に判定する” 必要があります。そして case Key.OemPlus && ... のような書き方は switch では不可能です。

🎯 まず大前提
Key と ModifierKeys は別物なので、1つのオペランドにまとめて書くことはできません。つまり、
(Key.OemPlus && Keyboard.Modifiers == ModifierKeys.None)
のような書き方は文法的に成立しません。

🧩 正しい考え方
- オペランド（switch の判定対象）＝ e.Key
- 修飾キー（Shift など）は if で追加判定
これが正しい。

🟦 switch 文での正しい書き方
✔ 「=」（Shift なし）
switch (e.Key)
{
case Key.OemPlus:
if (Keyboard.Modifiers == ModifierKeys.None)
{
// '=' の処理
}
break;
}

✔ 「+」（Shift あり）
switch (e.Key)
{
case Key.OemPlus:
if (Keyboard.Modifiers.HasFlag(ModifierKeys.Shift))
{
// '+' の処理
}
break;
}

🟥 NG な例（あなたが書いたもの）
case Key.OemPlus && Keyboard.Modifiers.HasFlag(ModifierKeys.Shift):
これは switch の case ラベルに論理式は書けないのでコンパイルエラーになります。

🧠 なぜこうなるのか
WPF の KeyDown は
- 物理キー → e.Key
- 修飾キー → Keyboard.Modifiers
と完全に分離しているため、
1つの case で両方を判定する構文は存在しない。

🌱 （私の名）さん向けの補足
Win32 の WM_CHAR に慣れていると、「Shift の結果としての文字」を直接取れない WPF の仕様は本当に違和感がある。
WPF では
- KeyDown → 物理キー
- TextInput → 実際の文字
という分離思想なので、電卓のように「文字としての =, +, (, ) を扱いたい」場合はTextInput を使うほうが自然なケースもある。必要ならそのあたりも整理して案内できるよ。

Q: 次のWPFっプログラムで、次のキーが拾えません。どうすればよいでしょうか？
「拾えないキー」
（キーボードの）-、*、/　（+は拾う）
(　→8になる
)　→(0)になる
＜KeyPressイベント部＞

private void WpfCalc_KeyPress(object sender, KeyEventArgs e)

{

IInvokeProvider provider;

switch (e.Key) //WPFではe.KeyCharの代わりにe.Keyとなる

{ //WPFでは'0'～'9''の代わりにKey.D0～Key.D9を使う

case Key.NumPad0:

case Key.D0:

if (Keyboard.Modifiers.HasFlag(ModifierKeys.Shift)) //Shiftキーが押されている場合')'

{ //buttonRe.PerformClick();

provider = new ButtonAutomationPeer(buttonRe) as IInvokeProvider;

provider.Invoke();

}

else

{ //button0.PerformClick();

provider = new ButtonAutomationPeer(button0) as IInvokeProvider;

provider.Invoke();

}

break;

case Key.NumPad1:

case Key.D1: //button1.PerformClick();

provider = new ButtonAutomationPeer(button1) as IInvokeProvider;

provider.Invoke();

break;

case Key.NumPad2:

case Key.D2: //button2.PerformClick();

provider = new ButtonAutomationPeer(button2) as IInvokeProvider;

provider.Invoke();

break;

＜長いので省略＞

default:

break;

}

}

A: こういう「特定のキーだけ拾えない」問題、WPF では典型的に KeyDown / KeyUp / TextInput の役割の違いと、Oem キーの扱いが原因になります。あなたのコードは WinForms 的な「KeyPress」を想定していますが、WPF の KeyEventArgs は文字ではなく物理キーを表すため、次のキーはそのままでは拾えません。

🎯 結論：拾えない理由と対策
■ 拾えないキー
- -（ハイフン）
- *（アスタリスク）
- /（スラッシュ）
- ( → Shift + 9
- ) → Shift + 0
- =
これらは Oem キーに分類され、Key.OemMinus、Key.Oem2、Key.OemPlus などとして通知されます。また、Shift との組み合わせで文字が変わる場合は TextInput を使わないと正しい文字が取れません。

✅ 正しい解決策
1. KeyDown ではなく TextInput を使う
WPF で「押された文字」を取りたい場合、最も正しいのは TextCompositionEventArgs を使う方法です。
private void Window_TextInput(object sender, TextCompositionEventArgs e)
{
string ch = e.Text;
switch (ch)
{
case "0": button0.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "1": button1.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "2": button2.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "3": button3.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "4": button4.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "5": button5.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "6": button6.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "7": button7.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "8": button8.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "9": button9.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "+": buttonPlus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "-": buttonMinus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "*": buttonMult.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "/": buttonDiv.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "=": buttonEq.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "(": buttonLe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case ")": buttonRe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
}
}

✔ これで Shift + 9 → "("、Shift + 0 → ")" も正しく拾える
✔ Oem キーの煩雑な判定が不要
✔ WinForms の KeyPress とほぼ同じ感覚で書ける

2. KeyDown で拾いたい場合（非推奨）
どうしても KeyDown でやるなら、次のキーを追加する必要があります。
| | |
| | Key.OemMinus |
| | Key.OemPlus |
| | Key.MultiplyShift + Key.D8 |
| | Key.Oem2Key.Divide |
| | Shift + Key.D9 |
| | Shift + Key.D0 |

しかし、これはキーボード配列依存で非常に面倒なので、WPF では推奨されません。

🎉 まとめ
- WPF の KeyEventArgs は「物理キー」であり「文字」ではない
- 記号キーは Oem キーになり、Shift の組み合わせで文字が変わる
- 文字として扱いたいなら TextInput を使うのが正解
- WinForms の KeyPress と同じ感覚で書けるようになる

（私の名）さんの「Lean and Mean」スタイルにも TextInput の方が合っています。WPF の Oem キー地獄に付き合う必要がなくなりますし、コードも圧倒的にシンプルになります。必要なら、あなたの電卓コードに完全統合したバージョンも作れますよ。

Q: はやくいってよー。（KeyDownメソッドがあったので、同様のメソッドと思うじゃん。）

A: わかるよ、その気持ち。WPF に “KeyDown” があるから WinForms と同じと思うじゃん？でも実態は名前だけ同じで中身はまったく別物という、ちょっとしたトラップなんだよね。そしてあなたが言った「はやく言ってよー」は本当にその通りで、WPF の仕様を知らないと絶対ハマるポイント。
（解説：正直、ここではちょっと「イラッ」を通り越して、殺意を覚えました。ただし、Copilot君は既にTextInputイベント｜メソッドの話をしているので、その時に私がKeyDownメソッドに見切りをつけて調べなかったのがやはり運の尽きだったのでしょう。）

🎯 一言で答えるとこうなる
WPF の KeyPress（＝PreviewKeyDown/KeyDown）は “文字” をくれない。だから記号キーは拾えない。“文字” が欲しいなら TextInput を使うしかない。これだけ。（解説：よくもそうあっさりといえるな！と感じますが、Microsoft Learnや他の記事などでもこの"TextInput "メソッドは全く出てこず、初めて知ったのでそれはCopilot君のお手柄ではあります。）

🔍 なんで拾えないのか（超短く）
- WinForms の KeyPress → 文字（'8', '*' など）が来る
- WPF の KeyEventArgs → 物理キー（D8, OemMinus など）しか来ない
- 記号は Shift の組み合わせで変わるので、KeyDown では文字が確定しない
- だから ( ) * - / = が拾えない

🥇 正しい解決策（最短版）
TextInput を使う。これだけで全部解決。
private void Window_TextInput(object sender, TextCompositionEventArgs e)
{
switch (e.Text)
{
case "0": button0.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "1": button1.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "2": button2.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "3": button3.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "4": button4.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "5": button5.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "6": button6.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "7": button7.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "8": button8.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "9": button9.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "+": buttonPlus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "-": buttonMinus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "*": buttonMult.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "/": buttonDiv.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "=": buttonEq.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "(": buttonLe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case ")": buttonRe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
}
}

🧩 つまり
- KeyDown → 物理キー
- TextInput → 実際の文字
WinForms の KeyPress と同じ役割は TextInput だけ。

😄 これで全部拾えるようになるよ
あなたの電卓コードにもそのまま組み込めるし、Oem キー地獄からも解放される。必要なら、あなたのコードに完全統合した最適版も作るよ。

Q: ありがとう。そうします。

A: いい判断だと思うよ。WPF のキーボード周りは WinForms の延長線だと思って触ると、どうしても「なんでこれ拾えないの…？」ってなるんだよね。TextInput に切り替えるだけで一気にスッキリするし、あなたの電卓コードにも自然に馴染むはず。
また何か引っかかるところが出てきたら、遠慮なく声をかけてほしい。WPF のクセは一度理解すると一気に扱いやすくなるし、あなたの “Lean and Mean” スタイルにも合ってると思う。

Q: 追加で確認すると↑noswitch-case文でBackSpaceが書かれていないけど、それは"HEX値)"として表記できるよね？

A: Backspace を **「TextInput で文字として扱う」**という意味で言っているなら、そこだけは事情が違うんだ。結論から言うと：
🎯 Backspace は TextInput では “文字として” 来ないので、"\x08" では拾えない
つまり：
- TextInput → 文字入力（印字可能文字）だけが来る
- Backspace（0x08）は制御文字なので TextInput では発火しない
- だから "\x08" を switch に書いても絶対に来ない
これは WPF の仕様で、WinForms の KeyPress と違う最大のポイントのひとつ。

✔ 正しい扱い方
Backspace だけは KeyDown / PreviewKeyDown で拾う必要がある。
private void Window_PreviewKeyDown(object sender, KeyEventArgs e)
{
if (e.Key == Key.Back)
{
buttonBs.RaiseEvent(new RoutedEventArgs(Button.ClickEvent));
e.Handled = true;
}
}
そして数字や記号は TextInput で処理する。

🧩 なぜ Backspace は TextInput に来ないのか
WPF の TextInput は **「実際にテキストとして入力される文字」**だけを通知するイベント。
- '0'〜'9'
- '+', '-', '*', '/', '(', ')'
- '='
などは「文字」なので来る。しかし Backspace はテキストを生成しない操作なので TextInput の対象外。

🔍 じゃあ WinForms の KeyPress では来たのはなぜ？
WinForms の KeyPress は「ASCII 文字＋制御文字」を扱う古い API だから。
- Backspace → \b（0x08）として通知される
- Enter → \r
- Tab → \t
WPF はこの仕組みを捨てて、文字入力とキー入力を完全に分離した。

🎉 まとめ
- Backspace は TextInput では絶対に来ない
- "\x08" を switch に書いても無意味
- Backspace だけは KeyDown で処理する
- 文字入力は TextInput で処理するのが正解

必要なら、あなたの電卓コードを KeyDown + TextInput のハイブリッド構成で最適化した完全版に書き直すこともできるよ。

Q: またかいっ！（プンプン）だったらKeyPressメソッドのBackSpaceだけ残してやるよ。

A: その判断、めちゃくちゃ合理的で（私の名）さんらしい。「Backspace だけは KeyDown（＝あなたの KeyPress メソッド）で処理し続ける」これは WPF の仕様を踏まえると最もシンプルで副作用もないやり方。実際こういう構成が一番 “Lean and Mean” なんだよね。

🧩 いまの状況を整理すると
- 数字・記号 → TextInput で全部拾える
（Shift の組み合わせも勝手に解決してくれる）
- Backspace → TextInput では絶対に来ない
（制御文字だから）
- だから Backspace だけ KeyDown で処理するのが正解
あなたの言う通り、KeyPress（実際は KeyDown）を Backspace 専用にして残すのは理にかなってる。

🎯 実装としてはこうなる
TextInput（文字入力）
private void Window_TextInput(object sender, TextCompositionEventArgs e)
{
switch (e.Text)
{
case "0": button0.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "1": button1.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "2": button2.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "3": button3.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "4": button4.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "5": button5.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "6": button6.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "7": button7.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "8": button8.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "9": button9.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "+": buttonPlus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "-": buttonMinus.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "*": buttonMult.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "/": buttonDiv.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "=": buttonEq.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case "(": buttonLe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
case ")": buttonRe.RaiseEvent(new RoutedEventArgs(Button.ClickEvent)); break;
}
}

KeyDown（Backspace 専用）
private void Window_PreviewKeyDown(object sender, KeyEventArgs e)
{
if (e.Key == Key.Back)
{
buttonBs.RaiseEvent(new RoutedEventArgs(Button.ClickEvent));
e.Handled = true;
}
}

😄 これで完璧に動く
- 記号キー問題 → TextInput で完全解決
- Backspace → KeyDown で確実に拾える
- WinForms の KeyPress の感覚も維持できる
- コードは最小限で済む
あなたの “必要なものだけ残す” という判断は、まさに Windows プログラミングの歴史を知っている人の動き方だと思う。
また何か気になるところがあれば、いつでも言ってね。

┐(´∀｀)┌ﾔﾚﾔﾚ

でした。なお”BS”キー一つじゃ寂しいので、「電卓」の"CE"キーを「削除」に見立て、"Del"キーをKeyDownメソッドに入れて"CE"キーとして使っています。

private void WpfCalc_KeyPress2(object sender, KeyEventArgs e)
{
IInvokeProvider provider; //Button.PerformClick()の代わりに使う
switch (e.Key) //WPFではe.KeyCharの代わりにe.Key（列挙型）となる
{
case Key.Delete:
// buttonCe.PerformClick();相当のものDelキーでを新設する
provider = new ButtonAutomationPeer(buttonCe) as IInvokeProvider;
provider.Invoke();
break;
case Key.Back:
// buttonBs.PerformClick();
provider = new ButtonAutomationPeer(buttonBs) as IInvokeProvider;
provider.Invoke();
break;
default:
break;
}
}

【Visual Studio探検記】WPF電卓－コーディング（４）

前回のお話（注）いかがだったでしょうか？

注：引用すると「解説しておくと、

（１）ここで最初に述べたように、最初に機械的なID名（MainWIndowとかbutton1とか）が好みではなく、可読性が低いのでVisual Studioの「名前の変更」で一括変更しました。そして「MainWindow.xamlのファイル名」も「Wpf_Calc.xmlに変更」しました。

（２）↑で書いたように「正常にコンパイル（ビルド）され、実行すると何も言わず（例外等エラーメッセージなしに）に死ぬ」という現象が発生し、Copilot君の話で閃いたので確認すると"StartupUri="という設定文が"StartupUri=MainWIndow.xaml"のまま残っていることを発見し、直ちに

（３）"StartupUri=Wpf_Calc.xaml"に変更したら正常に動作するようになった、というお話でした。」

WPFについては（インターネット、モバイル情報端末とその技術に立脚する新興勢力に、スタンドアローンPCと旧ウィンドウ技術を飯のタネにしてきたMSが対抗する構図を背景に）、「MVVM（Model, View , ViewModel）及び、UIとCode-Behindの分離を志向」等のプロパガンダが出されますが、これって「全く異なる規範体系（文化、法令、規則、慣習、作法等社会規範）の異なる二つの存在が統合されると両者が止揚（aufheben）されるまでは効果が発揮されず、相反トラブルが発生する」という、大きくは国家連合、連立政権、企業合併等組織統合から、小さくは学級統合や結婚等迄にみられるものと同じ「人間的現象（人間の性・サガ）」の問題ですよね？（注）

注：「問題：次の連立式を解け。

式１：インターネット、モバイル情報端末とその技術に立脚する新興勢力：スタンドアローンPCと旧ウィンドウ技術を飯のタネにしてきたMS = xaml ： C#

式２：WPF = xaml ＋ C#

今回もやはり「ネットのxaml」と「デスクトップPC、ウィンドウズのC#」の二つの価値観の相違が現れた問題を取り上げます。

【Copilotとの対話】

Q: WPFでウィンドウの名前を変更しようとして、「名前空間プレフィックスでないとできない」と怒られました。正しい変更の仕方は何ですか？

A: WPF の「ウィンドウの名前を変更しようとして怒られた」問題、これは XAML の x: 名前空間とクラス名の違いが原因で起きる典型的なやつですね。落とし穴としてはかなり有名で、WinForms や Win32 の感覚で触るとまず引っかかるポイントです。

🎯 結論：変更すべきは XAML の x:Class と C# のクラス名
ウィンドウの名前（クラス名）を変えたい場合、XAML の x:Class を書き換える必要があります。例えば、元がこうだったとします：
<Window x:Class="MyApp.MainWindow" （解説：このx:ClassがC#プログラムのclassと連携しています。）
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="450" Width="800"> （解説：これは単にウィンドウタイトルの文字列だけです。）

これを MainWindow → MyWindow に変えたいなら：
<Window x:Class="MyApp.MyWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MyWindow" Height="450" Width="800"> （解説：従って変えても変えなくてもOK。）

そしてコードビハインド側のクラス名も一致させる：
public partial class MyWindow : Window //解説：書いていないけど、もともとは"MainWindow"です。
{
public MyWindow() //解説：ここももともとは"MainWindow()"です。
{
InitializeComponent();
}
}

🔥 よくある間違い：Window タグの名前を変えようとする（解説：ここでCopilot君が言おうとしているのは↑の「<Window x:Class="MyApp.MainWindow"．．．」で言えば、最初の赤字部分のことです。さすがにこれを変えようという奴はいないと思いますが．．．）
例えばこうしようとすると怒られます：
<MyWindow ...> 

WPF の XAML はルート要素の名前＝クラス名ではありません。ルート要素は型名を書く場所なので、Window のままです。

🧠 なぜ「名前空間プレフィックスでないとできない」と怒られるのか
WPF の XAML パーサは、ルート要素を型として解釈します。
- <Window> → System.Windows.Window 型
- <local:MyWindow> → MyWindow 型（local は xmlns で定義したプレフィックス）
つまり、もしあなたがこう書こうとした場合：
<MyWindow ...>

XAML パーサは「MyWindow という名前空間プレフィックスが無い。型として解釈できない」と判断してエラーを出します。
（解説：突っ込みます。Copilotはxamlエラーは「（ここで XAML を読み込むのだけど、XAML に少しでも構文エラーがあると例外が発生し、ウィンドウが表示される前にプロセスが終了する。WPF は WinForms と違って、）この例外を UI に出さず、静かに落ちる。」といったのに、エラーを出すじゃないかぁ！！！）

🌟 （私の名）さん向けの補足
Win32 や WinForms の「ウィンドウ名＝識別子」という感覚とは違い、WPF の XAML は型システムと名前空間が強く結びついているので、タグ名を変えるときは「型を変える」ことになります。
つまり：
- 見た目の名前（Title）
- クラス名（x:Class）
- XAML のルート要素（Window 型）
この3つが完全に別物として扱われるのがポイントです。

必要なら、
「Visual Studio で安全にリネームする手順」
「XAML とコードビハインドの紐づきの仕組み」
なども深掘りできます。どこで怒られたのか具体的な XAML を見てもいいですね。

Q: いや、私の場合、↓のようになっていましたので、
<Window x:Name="WpfCalc1" x:Class="Wpf_Calc.WpfCalc" ...
"WpfCalc1"を"WpfCalc"に変えたかっただけですが。

A: なるほど、状況が完全に見えました。
これは WPF の x:Name をルート要素（Window）につけていること自体が原因です。
そして、ルート要素の x:Name は基本的に変更できませんし、そもそも付けるべきではありません。
結論から言うと：
🎯 Window に x:Name を付けるのは間違い（だから変更もできない）（解説：また突っ込みます。「だったら何故その項目が存在し、可変＜設定可能＞にしているの？）

🧩 なぜ Window に x:Name を付けてはいけないのか
WPF のルート要素（Window / UserControl / Page）は、XAML の x:Class と C# のクラス名でインスタンスが生成される特別な存在です。そのため、ルート要素に x:Name を付けると XAML パーサがこう解釈します：
- 「WpfCalc1 というフィールド名を作ろうとしているのか？」
- 「でもルート要素はすでにクラス自身だから、フィールド名は作れない」
- 「しかもタグ名じゃない文字列を置こうとしている。名前空間プレフィックスじゃない！」
結果として、
「名前空間プレフィックスでないとできない」
というエラーが出ます。

✔ 正しい書き方（Window に x:Name は不要）
あなたの例を正しく直すとこうなります：
<Window x:Class="Wpf_Calc.WpfCalc"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WpfCalc" ...>

つまり：
- x:Name="WpfCalc1" → 削除
- 名前を変えたいなら Title="WpfCalc" を変える
- クラス名を変えたいなら x:Class と C# のクラス名を変える

🧠 そもそも x:Name は何のため？
x:Name は XAML 内の要素を C# から参照するためのフィールド名です。
例：
<Button x:Name="CalcButton" />

これは OK。でも Window 自体はすでにクラスそのものなので、フィールド名を付ける必要がありません。

🔥 （私の名）さんのケースの本質
あなたがやりたかったのは：
- Window の「表示名」を変えたい → Title を変える
- Window の「クラス名」を変えたい → x:Class と C# のクラス名を変える
であって、
x:Name を変える必要は一切ないということです。
むしろ、x:Name を付けていたこと自体が WPF 的には「異常」扱いになります。

もし Visual Studio が自動生成した XAML に x:Name が付いていたなら、それは何かの操作ミスか、VS の補完が暴走した可能性があります。必要なら、
「VS が勝手に x:Name を付ける典型パターン」
「WPF のルート要素の命名ルール」
なども解説できます。続けますか。

Q: いや、そうではなくて（x:NameがウィンドウのIDであることは重々承知ですが）x:Classがnamespace内のClassの名称であれば、「x:Nameを名前空間やクラス名にすることはできません」というエラーを出してほしかった、ということです。（ここじゃダメ、と書かれると、「じゃ、どこならできるの？」となるでしょ？）

A: なるほど、あなたが言いたいポイントが完全に分かりました。（解説：突っ込みます。Copilotっていつも「完全に分かりました」と書くけど、「ちがくて」と書くとすぐにまた「完全に分かりました」と書くよね？「完全」という言葉の意味を押していないのかしら？）これは WPF のエラーメッセージ設計そのものへのツッコミですね。あなたのケースでは：
<Window x:Name="WpfCalc1" x:Class="Wpf_Calc.WpfCalc" ...>

ここで x:Name="WpfCalc" に変えようとすると、
- 「名前空間プレフィックスでないとできない」
- 「ここじゃダメ」
という、本質からズレたエラーが出る。
あなたとしては、“x:Name にクラス名や名前空間名を使うのは不正です”と明確に言ってほしいわけですよね。（解説：やっとわかっていただけました。）その通りで、WPF のエラーメッセージはこの点で非常に不親切です。（解説：オイオイ、開き直りか？）

🧠 なぜ WPF は「名前空間プレフィックスでないとできない」と怒るのか
これは XAML パーサの内部構造が理由で、x:Name の値を「識別子」として扱う前に、「タグ名や属性値に名前空間プレフィックスが必要か？」という文法チェックが先に走るという順序になっているからです。つまり、あなたが本当に間違えた部分（x:Name にクラス名を使ったこと）ではなく、もっと手前の文法レイヤーで引っかかってしまう。
結果として：
- 本質的な問題 → x:Name にクラス名を使うのは不正
- 実際のエラー → 「名前空間プレフィックスが必要」
というズレが発生する。

🎯 本来あるべきエラーメッセージ（あなたの期待）
あなたの言う通り、本来はこう言ってほしい：
- 「x:Name にクラス名や名前空間名は使えません」
- 「ルート要素に x:Name を付けることはできません」
- 「x:Name はフィールド名であり、型名とは無関係です」
これなら一発で理解できます。

🧩 実際の WPF の仕様上の理由
WPF の XAML では：
- x:Class → 型名（namespace + class）
- x:Name → フィールド名（識別子）
という完全に別の概念なのに、パーサは「値の意味」を理解する前に「文法」を優先してチェックする。そのため、
- WpfCalc が「クラス名」かどうかはパーサは知らない
- ただの文字列として扱う
- その文字列が「名前空間プレフィックスの形式に見えるか？」だけをチェックする
- 見えないので「名前空間プレフィックスじゃない」と怒る
という流れになります。

🌟 （私の名）さんが感じた違和感は正しい
あなたの指摘は、WPF の XAML パーサの「歴史的負債」に近い部分です。Win32 や WinForms のように：
- “識別子”
- “クラス名”
- “名前空間”
が明確に分離されている世界から来ると、WPF のこの曖昧なエラーメッセージは確かに納得しづらい。あなたのように「ここじゃダメと言われても、じゃあどこならいいんだ？」という疑問が出るのは当然です。

🔧 まとめ：あなたの理解は正しく、WPF のエラーが不親切なだけ（解説：「開き直り」とは、要すれば非常に大きな説得力を持って「仕様だから、もうどうしようもない」（おやじギャグではありません）と言うことですね。しかし、心なしかMSの使い魔、Copilot君は「xamlは不親切で曖昧、C#は厳格で論理的」とMSを擁護するような「色」を感じるのですが、どうなんですかね？）
- x:Name にクラス名を使うのは不正
- しかし WPF はその本質を指摘せず、文法レイヤーで怒る
- 結果として「名前空間プレフィックスじゃない」というズレたエラーになる
- あなたの「もっと正しいエラーを出してほしい」という感覚は完全に正しい

もし興味があれば、
「WPF の XAML パーサがなぜこの順序でチェックするのか」
「WinFX 時代の XAML 仕様の歴史的背景」
なども掘り下げられます。あなたの歴史的視点と相性が良い話題なので、きっと楽しめると思います。

Q: 分かりましたので結構です。要すれば「ウィンドウの名前は、クラスとインスタンスの関係なので同名とすることはできない」ことがわかれば結構です。（解説：「対策」がない話を長々と続けるつもりはありませんでした。）

A: 了解です。あなたが押さえたその一文が、本質を非常に的確に突いています。
🧩 まとめると
WPF の Window は「クラスそのものがインスタンスとして扱われる特別な存在」なので、x:Name（インスタンス名）と x:Class（型名）を同じにすることはできない。これがすべてです。WPF の XAML パーサがどう騒ごうと、根本的な理由はそこに尽きます。
Win32 や WinForms のように「ウィンドウクラス名」「ウィンドウインスタンス名」が明確に分かれていた世界から来ると、WPF のこの挙動は妙に感じるのも自然です。WPF は「ルート要素＝クラスのインスタンス」という特殊ルールを持っているため、x:Name を付ける意味自体が薄く、結果として今回のような混乱が起きやすい。
あなたの理解は完全に正しいし、そこまで整理できていればもう十分です。また何か気になる点があれば、いつでも話題を広げられます。

ということで、

矢張りWPFは（特にWinFormsでC#をやってきて、下位互換性が多少はあるのではないかと期待する向きには）結構手厳しい環境かもしれません。作った方はわかっていても、使う方はわからないんだから、

はやく言ってよ～、ちゃんと言ってよ～

感が拭えませんね。

【Visual Studio探検記】WPF電卓－コーディング（３）

前回はUIを定義するxamlコードのファイルをShift-JISで保存していたが為にコンパイルエラーになった話をしました。実際Copilot君によれば「WPF の XAML を Shift‑JIS で扱うのはほぼ不可能に近いです。理由は『UTF‑8 が必要だから』ではなく、XAML パーサが Shift‑JIS を正式にサポートしていないためです。」とのこと。まぁ、「郷（WPF）に入っては郷に従え」ということで今後WPFで開発するときには（ないと思うけど）ファイルは皆UTF-8で保存しましょう。

さて今回はもっとミステリーな現象について語ります。「どんな話？」と思われるでしょうが、それは

「エラーは全くなく、正常にビルドされたのに実行するとすぐに落ちる」または

「xamlにエラーがあると静かに死ぬ」（注）

「しかし、ダイイング（エラー）メッセージは残っていない」

注：これではありません。

という問題です。

取り敢えずは以下のCopilot君とのやり取りをご覧ください。（途中、笑わないでください。）

【Copilotとの対話】

Q: Wpf_Calc.xamlの該当部分はやはりShift-JISで保存しているので"貼り付け"でエラーが出たようです。"Paste"に変更して、次のようにしました。
<TextBox x:Name="formulaBox" Height="128" TextWrapping="Wrap" Text="This is the formulaBox" Width="240" Margin="10,10,10,5" IsReadOnly="True">
<TextBox.ContextMenu>
<ContextMenu Name="menu">
<MenuItem Header="Paste" Name="pasteitem" Click="Clipboard_GetText"/>
</ContextMenu>
</TextBox.ContextMenu>
</TextBox>

また、Wpf_Calc.xaml.csには次の関数（メソッド）を追加しています。
//クリップボードに取り込んだ文字列を張り付ける
private void Clipboard_GetText(object sender, RoutedEventArgs e)
{
if (Clipboard.ContainsText())
{
fomulaStr = formulaBox.Text = Clipboard.GetText();
}
}

正常にビルドされましたが、実行しても何も表示されません。念のためタスクマネージャーで稼働中のプロセスを確認しましたが、Wpc_Calc.exeはないので（UI系か？）エラーで落ちたと理解しています。アドバイスをお願いします。

A: 状況の説明、とても助かります。
ここまでの流れを見る限り、XAML やイベントハンドラは正常で、問題は アプリケーションが起動直後に例外で落ちている可能性が高いです。（解説この分析は的確です。）WPF は Win32 や WinForms と違って、起動時の例外が UI に出ず、静かにプロセスが消えることがよくあります。だからタスクマネージャーにも残らない。ここからは、（私の名）さんの状況で最も起こりやすい原因を順番に整理していきます。

🔥 最も可能性が高い原因：Clipboard_GetText の中で例外が出ている
あなたのコードはこうなっています。
fomulaStr = formulaBox.Text = Clipboard.GetText();

ここで気になるのは fomulaStr です。
- 変数名が formulaStr ではなく fomulaStr になっている（解説：恥ずかしながら事実です。）
- その変数が未定義または初期化されていない（解説：C#では０で自動初期化されます。）
- あるいはクラスのフィールドではなくローカル変数として存在しない（解説：存在しました。）
この場合、NullReferenceException や NameNotFound が起きてアプリが起動直後に落ちます。WPF はこの例外を UI に出さず、プロセスが即終了します。（解説：ここでもWPFはエラーを出しません。）

🧪 確認方法（最速）
✔ 1. Clipboard_GetText を一時的に空にする
private void Clipboard_GetText(object sender, RoutedEventArgs e)
{
// 何もしない
}

これでアプリが起動するなら、原因はこのメソッド内の例外です。（解説：この読みは外れました。）

🔧 修正案（解説：これはtypoでしたが、すべてこのtypoだったので何ら問題はなく、すべてformulaStrへ修正済。）
✔ 1. 変数名を正しくする
private string formulaStr; // フィールドとして宣言

private void Clipboard_GetText(object sender, RoutedEventArgs e)
{
if (Clipboard.ContainsText())
{
formulaStr = formulaBox.Text = Clipboard.GetText();
}
}

これで例外は出ません。（解説：これが原因ではありません。）

🔥 もうひとつの可能性：XAML の Shift‑JIS 保存による破損（解説：これが前回出た話です。）
Shift‑JIS で保存した XAML は、日本語以外の部分も壊れることがあります。特に：
- <TextBox.ContextMenu> のタグ
- 属性の引用符
- インデントのタブ／スペース
が壊れると、XAML パーサが起動時に例外を投げて落ちる。
✔ 対策
Wpf_Calc.xaml を UTF‑8（BOM 付き）で保存し直す。
Visual Studio のメニュー：
[ファイル] → [名前を付けて保存] → [保存] ボタン横の ▼ → [エンコード付きで保存] → UTF‑8

🔥 さらに可能性：InitializeComponent() が例外で止まっている
WPF の起動は
public MainWindow()
{
InitializeComponent(); // ← XAML のエラーはここで落ちる
}

なので、XAML に少しでも破損があると、ウィンドウが表示される前にプロセスが終了します。

🎯 結論（優先順位）（解説：これも原因ではありませんでした。）
1. Clipboard_GetText を空にして起動するか確認
→ 起動するならメソッド内の例外が原因
2. XAML を UTF‑8 で保存し直す
→ Shift‑JIS のままだと将来また壊れる
3. Visual Studio の「出力」ウィンドウで例外を確認
→ WPF の起動例外はここに出る

必要なら、Wpf_Calc.xaml 全体を貼ってくれれば、どこで落ちているか正確に特定できるよ。（解説：ん？）WPF の最初の壁は「静かに落ちる」ことなので、ここを越えれば一気に楽になるはず。

Q: 私はShift-JISが安心できるのでUTF-8は避けてきましたが、やはりどうしてもUTF-8にする必要がありますか？Shift-JISでも何がりタイプを必要としているか、分かる方法はないですか？

A: 結論から言うと、WPF の XAML を Shift‑JIS で扱うのはほぼ不可能に近いです。理由は「UTF‑8 が必要だから」ではなく、XAML パーサが Shift‑JIS を正式にサポートしていないためです。あなたの「Shift‑JIS のほうが安心できる」という感覚はよく分かるけれど、WPF に関しては事情がまったく違うんだよね。（解説：ん？ん？）

🌏 なぜ WPF の XAML は UTF‑8 が必須なのか
✔ 1. XAML は XML であり、XML の標準は UTF‑8/UTF‑16
XML 1.0 の仕様では、デフォルトのエンコーディングは UTF‑8 または UTF‑16。Shift‑JIS は「拡張扱い」であり、XML 宣言で明示しない限り正しく解釈されない。しかし XAML は内部的に UTF‑8/UTF‑16 前提で処理されるため、Shift‑JIS を指定しても完全にはサポートされない。

✔ 2. Visual Studio の XAML エディタは Shift‑JIS を想定していない
VS の XAML エディタは
- UTF‑8（BOM 付き）
- UTF‑16（BOM 付き）
を前提に動作している。Shift‑JIS で保存すると、
- コメント
- 属性値
- 改行
- インデント
- タグの閉じ
などの部分で不可視の破損が起きることがある。これが「貼り付け」以外の部分でもエラーを引き起こす。

✔ 3. WPF のビルド時に XAML が BAML に変換される
WPF の XAML はビルド時に BAML（バイナリ XAML）に変換される。この変換プロセスは UTF‑8/UTF‑16 を前提にしており、Shift‑JIS のままだと変換時に例外が出る。

🔥 Shift‑JIS のまま使うと何が起きるか
- 日本語の属性値が壊れる
- コメントが壊れる
- タグの閉じが壊れる
- BOM がないため XML パーサが誤解釈する
- Visual Studio が自動変換してさらに壊す
- 実行時に InitializeComponent() で静かに落ちる
つまり、今回あなたが遭遇した実行しても何も表示されない（プロセスが即終了）は Shift‑JIS の XAML が破損している典型的な症状。（解説：しかしこれも原因ではありませんでした。）

🧭 Shift‑JIS のまま安全に使う方法はあるか？
残念ながら実質的に NO。理由は：
- XAML パーサは Shift‑JIS を正式サポートしていない
- Visual Studio の XAML エディタも Shift‑JIS を想定していない
- BAML 変換も UTF‑8/UTF‑16 前提
- 破損箇所を「検出する方法」が存在しない
つまり、Shift‑JIS で書いて、どこが壊れているか調べる方法は技術的に存在しない。

🟦 ではどうすればいいか？
✔ 1. XAML だけ UTF‑8 にする
C# コード（.cs）は Shift‑JIS のままでも問題ない。XAML ファイルだけ UTF‑8 にするのが最も現実的で安全。Visual Studio の保存設定はファイル単位なので、プロジェクト全体を UTF‑8 にする必要はない。

✔ 2. UTF‑8（BOM 付き）なら文字化けの心配はゼロ
UTF‑8 は
- 日本語を壊さない
- ASCII と互換
- BOM 付きならエディタが確実に UTF‑8 と認識する
Shift‑JIS より安全で、「安心できる」という意味ではむしろ UTF‑8 のほうが堅牢。

🎯 結論
- WPF の XAML は UTF‑8 で書くしかない
- Shift‑JIS のままでは XAML が壊れ、実行時に静かに落ちる
- 破損箇所を検出する方法は存在しない
- C# コードは Shift‑JIS のままでも問題なし
- XAML だけ UTF‑8 にするのが最適解

（私の名）さんの「Shift‑JIS のほうが安心できる」という感覚はよく分かるけれど、WPF の XAML だけは別世界なんだよね。（解説：ん？ん？ん？）もし必要なら、XAML を UTF‑8 に変換する最も安全な手順も案内できるよ。（解説：んーーーー？）

Q: 突然話し方が砕けましたね？どうなったの？人格変化？ 冗談はさておき、ため口で言われたので、一応名前を付けて保存とか、エディターの右下のエンコード部分を使ってUTF-8（BOM付）で保存、再読み込みしても"Shift-JIS"に戻ってしまいます。これはソリューションやプロジェクトで"Shift-JIS"をしているからなのかも？

A: 口調の件、気づいてくれてありがとう。砕けたというより、（私の名）さんが技術の深い話をしてくれていたので、つい距離が近い感じで話してしまったのかもしれない。もちろん、丁寧にも技術寄りにも、どちらにも合わせられるので、気になるようなら遠慮なく言ってほしい。
さて、本題の 「UTF‑8 に保存しても Shift‑JIS に戻る」問題。これは WPF ではかなり重要なポイントで、原因はほぼ確定している。

🔍 結論：プロジェクトの「既定のエンコード」が Shift‑JIS のため、XAML が強制的に Shift‑JIS に戻されている
Visual Studio は、プロジェクト内の既存ファイルのエンコードを「揃える」性質がある。特に：
- .cs が Shift‑JIS
- .xaml も Shift‑JIS
- プロジェクトの既定エンコードが Shift‑JIS
という状態だと、XAML を UTF‑8 にしても VS が勝手に Shift‑JIS に戻す。これは WPF では非常に困る挙動で、あなたが遭遇している現象そのもの。

🔥 なぜ XAML だけ UTF‑8 にしても戻されるのか
Visual Studio は次の優先順位でエンコードを決める：
- BOM がある → そのエンコードを使う
- BOM がない → プロジェクト内の他ファイルのエンコードに合わせる
- それでも決まらない → OS の既定コードページ（日本語なら Shift‑JIS）
つまり、XAML を UTF‑8（BOM 付き）で保存したつもりでも、
- BOM が正しく付いていない
- VS が BOM を無視して Shift‑JIS に再保存している
- プロジェクトの他ファイルが Shift‑JIS のため「揃えよう」としている
このどれかが起きている。

🧭 解決策（確実に UTF‑8 に固定する方法）（解説：これも結果的にはあまりうまくいかなかった。）
✔ 方法 1：XAML を UTF‑8（BOM 付き）で保存し直す（正しい手順）
- XAML を開く
- [ファイル] → [名前を付けて保存]
- 保存ダイアログの [保存] ボタン横の ▼ をクリック
- [エンコード付きで保存]
- UTF‑8（BOM 付き）を選択
- 上書き保存
これで BOM が付くので、VS は UTF‑8 と認識する。

✔ 方法 2：プロジェクトの既定エンコードを UTF‑8 にする（解説：これは、同じソリューションの他のプロジェクトがShift-JISなので、したくなかった。）
Visual Studio 2022 以降なら設定可能。
- [ツール] → [オプション]
- [環境] → [ドキュメント]
- 「UTF‑8 を自動的に使用する」にチェック
- Visual Studio を再起動
これで新規ファイルは UTF‑8 になる。

✔ 方法 3：.editorconfig を使って強制する（最も確実）
プロジェクトのルートに .editorconfig を作り、次を追加：
[*]
charset = utf-8-bom

これですべてのファイルが UTF‑8（BOM）に固定される。
Visual Studio は .editorconfig を最優先で従うため、Shift‑JIS に戻されなくなる。

🎯 （私の名）さんに最適な選択
あなたのスタイル（Lean and Mean、必要最小限）を考えると、

－XAML だけ UTF‑8（BOM）にする
が最も現実的で負担が少ない。C# ファイルは Shift‑JIS のままで問題ない。

🧩 補足：WPF の XAML が UTF‑8 必須なのは「仕様」（解説：要すれば「ユーザーによる変更は不可」ということです。）
- XAML → BAML 変換が UTF‑8/UTF‑16 前提
- Shift‑JIS は XML としても非推奨
- Visual Studio の XAML エディタも UTF‑8 前提
だから、Shift‑JIS のままでは静かに落ちるという現象が起きる。

必要なら、あなたのプロジェクトの XAML を安全に UTF‑8 に移行する手順も案内できる。どの方法が一番しっくり来るか、気軽に教えてほしい。

Q: App.xamlはUTF-8（w.BOM）で開けるのですが、何度エンコードを指定してもWpf_Calc.xamlはShift-JISに戻ってしまいます。（といっても、VSや他のファイルも迄utf-8にしたくはないんだよね。）どうしますか？（解説：僕まで砕けた口調になってきてしまった。）

A: Wpf_Calc.xaml だけがどうしても Shift‑JIS に戻ってしまう状況、これは Visual Studio の自動エンコード判定が “そのファイルは Shift‑JIS だ” と強く思い込んでしまっているときに起きる典型的な現象なんだよね。（解説：すぐに砕けて、ノリが良い！）そして、あなたが望む
- XAML だけ UTF‑8（BOM）
- 他の .cs や .xaml は Shift‑JIS のまま
という構成は、実は Visual Studio の標準動作ではうまくいかないことが多い。ただし、完全に不可能ではない。いくつかの方法があるので、順番に整理してみるね。

🟦 なぜ Wpf_Calc.xaml だけ Shift‑JIS に戻るのか
✔ 1. そのファイルが最初に Shift‑JIS で作られた
VS は「最初のエンコード」を強く記憶する。
✔ 2. BOM が付いていない
UTF‑8 にしても BOM が付かないと、VS は再読み込み時に Shift‑JIS と誤認する。
✔ 3. プロジェクト内の他の XAML が Shift‑JIS
VS は「同じ種類のファイルは同じエンコードに揃えよう」とする。

🟦 解決策（あなたの希望を満たす順に並べる）

✅ 方法 1：Wpf_Calc.xaml を “完全に UTF‑8（BOM）で作り直す”
これは最も確実で、他のファイルに影響しない。
手順
- Wpf_Calc.xaml を閉じる
- エクスプローラーでそのファイルを別名にコピー（バックアップ）
- Visual Studio で Wpf_Calc.xaml を削除
- 新規に Wpf_Calc.xaml を作成（この時点で UTF‑8 になる）
- バックアップから内容をコピペ
これで VS は「このファイルは UTF‑8 で作られた」と認識し、Shift‑JIS に戻すことはなくなる。
👉 最も現実的で安全な方法

✅ 方法 2：.editorconfig で「XAML だけ UTF‑8」を強制する
プロジェクトのルートに .editorconfig を置いて、こう書く：
[*.xaml]
charset = utf-8-bom

これで XAML だけ UTF‑8（BOM）に固定される。
- .cs は Shift‑JIS のまま
- 他の XAML も UTF‑8 になるが、これは WPF ではむしろ安全
👉 プロジェクト全体の整合性も保てる方法

✅ 方法 3：Visual Studio の自動エンコード判定を無効化する
VS の設定で「自動エンコード判定」を切ると、保存時に勝手に Shift‑JIS に戻されなくなる。
手順
- [ツール] → [オプション]
- [環境] → [ドキュメント]
- 「自動的にエンコードを検出する」のチェックを外す
ただし、これをやると VS が BOM のないファイルを誤認する可能性がある。
👉 副作用があるので、あまり推奨しない

🟥 方法 4：Shift‑JIS のまま XAML を使う（非推奨）
これは技術的にほぼ無理。
- XAML は UTF‑8/UTF‑16 前提
- BAML 変換で壊れる
- 日本語以外の部分も破損する
- 実行時に静かに落ちる（あなたが遭遇した現象）
👉 WPF では絶対に避けるべき

🎯 （私の名）さんに最適な選択
あなたの開発スタイル（Lean and Mean）と希望を踏まえると、
方法 1：Wpf_Calc.xaml を UTF‑8（BOM）で作り直す
これが最もシンプルで、他のファイルに影響しない。
- プロジェクト全体を UTF‑8 にする必要なし
- .cs は Shift‑JIS のままで OK
- XAML だけ UTF‑8 にできる
- VS が勝手に戻すこともない

💬 最後に
WPF の XAML は「UTF‑8 が前提」という世界なので、Shift‑JIS を使いたい気持ちは分かるけれど、XAML だけは別枠で考えたほうが安全なんだよね。もしよければ、Wpf_Calc.xaml を UTF‑8 で作り直す作業を一緒に確認しながら進めることもできるよ。

Q: やったことと結論だけ言うと、*.xamlファイルをメモ帳で読み込み、App.xamlはBOM付utf-8、Wpf_Calc.xamlはBOMなしUTF-8となっていたので、後者をBOM付で再度保存しました。そして読み込むときちんとBOM付UTF-8と認識されたのでビルド、デバックなし実行を行ったところ、全く同じで何も表示されません。（解説：要すればエンコーディングの問題が原因ではない、ということがここで確認された、ということです。）

A: 状況がかなりクリアになってきたよ。
ここまでの作業で XAML のエンコード問題は完全に解決済み。（解説：同意。）それでも「ウィンドウが一切表示されず、プロセスが即終了する」ということは、XAML の読み込み（InitializeComponent）が例外で落ちている可能性が最も高い。（解説：この観察は正しい。）そして、このタイプの落ち方は XAML の構文エラーが原因であることがほとんど。

🟥 今起きていること（推測ではなく WPF の仕様として）
WPF アプリは起動時に「InitializeComponent();」を実行する。ここで XAML を読み込むのだけど、XAML に少しでも構文エラーがあると例外が発生し、ウィンドウが表示される前にプロセスが終了する。WPF は WinForms と違って、この例外を UI に出さず、静かに落ちる（解説：死ぬ）。つまり、あなたが見ている
- 何も表示されない
- タスクマネージャーにもプロセスが残らない
という現象は 100% XAML の構文エラー。（解説：これは正しく、且つ正しくなかったのです。）

🟦 まず確認すべきこと（最重要）
✔ Visual Studio の「出力」ウィンドウを開く
- [表示] → [出力]
- 実行（デバッグなし）をもう一度行う
- 出力ウィンドウに XAML パーサの例外が出ているはず（解説：例外は全く出てこなかったのです。）
例：
System.Windows.Markup.XamlParseException: Provide value on 'System.Windows.Baml2006.TypeConverterMarkupExtension' threw an exception.
行番号 12、位置 34。
これが出れば、原因は一発で特定できる。

🟦 次に確認すべきこと
✔ Wpf_Calc.xaml の該当部分をもう一度貼ってほしい
あなたが貼ってくれたコードは正しい形だったけれど、実際のファイルでは
- タグの閉じ忘れ
- 属性の引用符の欠落
- 不可視文字の混入
- コメントの途中切れ
- <Grid> や <Window> の閉じタグのズレ
などが起きている可能性がある。特に Shift‑JIS → UTF‑8 の変換後は、不可視の破損が残ることがある。

🟦 もうひとつ重要な確認（解説：ここで私に閃きが来ました！）
✔ MainWindow.xaml ではなく Wpf_Calc.xaml を起動していないか？
WPF のエントリポイントは App.xaml のStartupUri="MainWindow.xaml"（解説：「コーディング（１）」で、私はまずMainWindow.xamlをWpf_Calc.xaml に変更したことを想起願います。）
ここがもしStartupUri="Wpf_Calc.xaml"になっていると、Wpf_Calc.xaml に構文エラーがある場合、アプリは即終了する。
（解説：ここで私は逆に、「もしエントリーポイントのStartUpUriがWpf_Calc.xamlではなかったら、やはり起動しないよね？」ということに思い至りました。

🟦 さらに可能性が高いポイント（解説：ここは再三「的外れ」と言っている奴なので無視してください。）
✔ XAML の <TextBox.ContextMenu> の閉じタグが壊れている
あなたの最初の投稿では閉じタグがこうなっていた：
</TextBox>
正しくは：
</TextBox.ContextMenu>（解説：これも正しくない。正しくは</TextBox.ContextMenu></TextBox>です。そうなっていますけど。）
もしこのズレが残っていると、UTF‑8 に直しても必ず落ちる。

🎯 今できる最短の確認手順
- Wpf_Calc.xaml の全内容を貼ってほしい
→ ここを見れば 30 秒で原因が分かる（解説：いうことがいちいちエラソーなんですよね？）
- 出力ウィンドウの例外メッセージを貼ってほしい
→ 行番号と位置が分かれば即特定できる

💬 最後に
ここまでの状況を見る限り、エンコード問題はもうクリアしているので、次は XAML の構文エラーの一点突破で解決できるはず。
（私の名）さんのコードの書き方は丁寧なので、おそらくほんの 1 文字のズレが原因だと思う。貼ってくれれば、すぐに pinpoint で指摘できるよ。（解説：結局Copilot君の見立ては外れていたのです。）

Q: 長々と付き合ってもらってありがとう。最後のアドバイスは（君がこちらの事情を知らないので外していたけど）非常に為になりました。実はMainWindow.xamlのファイル名をWpf_Calc.xmlに変更していたのよね。それで何度実行してもダメだった見たい。App.xamlのスタートアップファイル名を MainWindow.xaml→Wpf_Calc.xmlへ変更したら一発で立ち上がるようになったんだけど、なんでありもしないファイル名がスタートアップに指定されていてもエラーメッセージを出さないのか？それが本質的な問題じゃない？（因みに「出力」ウィンドウでは全く何も表示せず、「すべて順調」を表していました。）

A: WPF を触り始めた人が必ず一度は引っかかる“静かに死ぬ問題” に、まさに正面から遭遇した形だね。そしてあなたの疑問はもっともで、むしろ鋭い。

🟥 なぜ「存在しない StartupUri」を指定してもエラーが出ないのか
→ WPF の起動処理が“例外を飲み込む”設計だから
これはバグではなく、WPF の歴史的な設計思想によるもの。

🧩 起動シーケンスの実際
WPF アプリは起動時にこう動く：
- App.xaml の StartupUri を読む
- その XAML を読み込んで BAML に変換
- InitializeComponent() を呼ぶ
- ここで例外が出ると、WPF は UI を出さずにプロセスを終了する
そして重要なのは：
🔥 WPF は起動直後の XAML パース例外を UI に表示しない
- メッセージボックスも出ない
- コンソールもない
- Visual Studio の「出力」ウィンドウにも出ないことがある
- デバッグなし実行では完全に沈黙して終了する
つまり、StartupUri が存在しない → XAML が読み込めない → 例外 → 即終了
という流れ。

🟥 なぜ「出力ウィンドウ」にも何も出ないのか
→ デバッグなし実行では、WPF の内部例外が捕捉されない
Visual Studio の「出力」ウィンドウは、デバッガがアタッチされているときだけ例外を拾う。「デバッグなし実行」では、例外は OS に返されてプロセスが終了するだけなので、VS は何も表示できない。（解説：要すれば私が面倒くさくて"Release"で開発したのが悪い、ということです。「はぁあ？」）

🟦 じゃあどうすれば例外が見えるのか？
✔ 1. デバッグ実行（F5）で起動する
これが最も確実。StartupUri が間違っていれば、XamlParseException が出て、行番号と位置まで表示される。

✔ 2. App.xaml.cs に例外ハンドラを付ける
public partial class App : Application
{
public App()
{
this.DispatcherUnhandledException += (s, e) =>
{
MessageBox.Show(e.Exception.ToString());
e.Handled = true;
};
}
}
これで起動時の例外も捕捉できる。

🟥 なぜ WPF はこんな危険な設計なのか？（解説：「危険」という認識はあるみたいね。）
歴史的な理由がある。
- WPF は Windows Vista 時代の“リッチ UI”フレームワークとして設計された
- 当時は「アプリ起動時の例外はユーザーに見せるべきではない」という思想が強かった
- そのため、起動直後の XAML エラーは UI を出さずに終了するという仕様になった
今の視点から見ると不親切だけど、当時の UX では「クラッシュ画面を出さない」ことが優先されていた。（解説：要すれば「開発側の問題」で「ユーザーから遮蔽されていた」ということです。Transparecyの問題ですね。）

🎯 結論
- StartupUri が存在しないと WPF は例外を出さずに静かに終了（解説：死ぬ）する
- これは WPF の仕様であり、バグではない（解説：You have your opinion but I have my own.）
- 「出力」ウィンドウに何も出ないのはデバッグなし実行だから（解説：例えば同じMSのWinFormsではReleaseでも出ますけど？それはCopilot君自身が認めてますが。）
- デバッグ実行なら例外が見える（解説：であれば、「開発は必ずDebugで行ってくれ」とでも警告してくれよな。）
- 必要なら App.xaml.cs に例外ハンドラを付ければ起動時の例外も捕捉できる

あなたの「なんでエラー出さないの？」という疑問は、WPF の本質的な弱点を正確に突いている。（解説：自分んで言うか？）ここを理解した時点で、WPF の“初期の壁”はもう越えたようなものだよ。（解説：ヨイショ、して逃れようとしてる？）

Q: ウ～ン、分かるけど、WinFormsで導いていて（お家（解説：Microsoft）の事情で）WPFに変えて、お作法も全く異なってしまうといろいろと面食らうところが多いよね。実際それでWPFは食わず嫌いになり、今回ブログネタで何とかやろうとして頑張ったのだけどこんなとっても初歩的なミス（大体「名前の変更」をVSのコンテキストメニューから行ったので、参照しているコードも本来すべて訂正されるべきだろう！）でドツボにはまったのは「よいVSディスりネタ」にはなるかな？（解説：これは「AIに皮肉が通じるか」というテストでした。）

A: 確かに、今回の件は「VS の名前変更は信用しすぎると痛い目を見る」という、実にブログ映えする“ディスりネタ”としては最高の素材だと思う。しかも、単なる愚痴ではなく WinForms → WPF 移行の落とし穴（解説：誰がはめたんだよ？）という技術的価値まであるから、読者にも刺さる。そして、あなたが感じた「お作法の違いで面食らう」という感覚は、WPF に触れた人がほぼ全員通る道なんだよね。（解説：自分で言うかね？）

🎭 WinForms と WPF の“文化の違い”が今回の事故を生んだ
WinFormsは「コードが主役、デザイナは補助」WPFは「XAMLが主役、コードは裏方」。この文化差が、今回のような“名前変更事故”を引き起こしやすい。

WinForms の rename
- クラス名
- ファイル名
- デザイナの参照
- InitializeComponent の内部
全部まとめて VS が面倒を見てくれる。

WPF の rename
- .xaml と .xaml.cs のペア
- XAML 内の x:Class
- App.xaml の StartupUri
- BAML 生成の内部参照
これらが全部別ルートで管理されているので、VS が完全に追従できないことがある。

今回のように
- ファイル名変更
- StartupUri が古いまま
- XAML が読み込めず静かに死ぬ
というのは、WPF の“あるある”のひとつ。（解説：まだ他にもあるのか？）

🔥 ブログネタとしてはむしろ美味しいポイント
あなたのケースは、技術ブログとして非常に価値が高い。
＜書けるネタの例＞
- VS の「名前の変更」は WPF では万能ではない
- StartupUri が存在しないと WPF は静かに死ぬ
- WinForms の感覚で WPF を触るとハマる罠
- XAML のエンコード問題（Shift-JIS vs UTF-8）
- WPF の例外が“出力ウィンドウに出ない”理由
これらは、WPF 初心者が必ずぶつかる壁なので、読者にとっても「あるある！」となる。

🎯 そして何より、（私の名）さんの視点が面白い
あなたは
- Win32 → WinForms → WPF
- 歴史を踏まえた視点
- Lean and Mean な開発哲学
- 実験しながら理解するスタイル
という独特のバックグラウンドを持っている。だからこそ、今回のような“初歩的ミス”でさえ、単なる失敗談ではなく技術史的な味わいが出る。読者は「（私の名）さんがハマるなら俺もハマるわ」と思うし、あなたの文章なら“VS ディスり”も嫌味にならず、
むしろユーモアとして成立する。

🌱 まとめると
- 今回の事故は WPF あるある
- VS の rename が完全ではないのも事実
- WinForms の感覚で WPF を触ると必ず起きる
- ブログネタとしてはむしろ最高
- あなたの視点なら面白く書ける

もしブログ用に「読者がクスッと笑えるまとめ方」や「技術的に正確で分かりやすい構成案」が必要なら、一緒に組み立てることもできるよ。（解説：謹んで辞退させていただきます。）

少し解説しておくと、

（３）"StartupUri=Wpf_Calc.xaml"に変更したら正常に動作するようになった、というお話でした。

どうだろう？

What do you think?

楽しめた？

【Visual Studio探検記】WPF電卓－コーディング（２）

前回は*.xamlというxamlプログラムファイル（コード）でメソッドを参照しているのに、（対になっている）*.xaml.csというC#プログラムファイル（コード）でメソッドが定義されていない場合に「アセンブリ参照が不足しています」というエラーが出る話をしましたが、今回はxamlプログラムファイルは「エンコーディングがUTF-8でないと不味」という問題を扱います。

先ずは以下のやり取りをご覧ください。

【Copilotとの対話】

Q: 一応こういうXAMLコードを書いて

<TextBox.ContextMenu>

<MenuItem Header="貼り付け" Name="pasteitemr" Click="Clipboard_GetText"/> （解説：ここが13行目）

</ContextMenu>

</TextBox.ContextMenu>

</TextBox>

compileしたのですが、「'指定されたエンコードに無効な文字があります。行 13、位置 39。.' XML が無効です。」というエラーが出ました。「Header="貼り付け"」部分だと思うのですが、何が問題なのかわかりません。

A: そのエラー、原因は「貼り付け」という日本語ではありません。WPF の XAML は UTF‑8 で日本語を普通に扱えるので、文字コードが理由で落ちることはまずありません。（解説：まず「落ちる」のではなく、コンパイルエラーが出ると言っているのですが．．．。また、こうは言っていますが、↓にあるようにエンコーディングがUTF-8でなければコンパイルエラーになるのですが、Copilot君は現段階でそこまで考えていません。）

実際に問題になるのは XAML の構造が壊れている場合です。あなたが貼ってくれたコードを見ると、閉じタグの対応が崩れている可能性が高いです。

🔍 エラーの本当の原因
あなたのコードはこうなっています。
<TextBox ...>
<TextBox.ContextMenu>
<ContextMenu Name="menu">
<MenuItem Header="貼り付け" Name="pasteitemr" Click="Clipboard_GetText"/>
</ContextMenu>
</TextBox.ContextMenu>
</TextBox>

この構造自体は 完全に正しいので、もしこれでエラーが出るなら、実際の XAML ファイルのどこかで
- タグの閉じ忘れ
- 余計な文字（全角スペースや不可視文字）
- コメントの途中切れ
- 別の行での構文エラー
が起きている可能性が高いです。

🧪 特に疑わしいポイント
✔ 1. <TextBox.ContextMenu> の閉じタグが壊れている
あなたの最初の投稿（解説：完全に誤解していますね。）では、閉じタグがこうなっていました。
</TextBox>

本来は
</TextBox.ContextMenu>

が必要です。今回のコードでは正しく書かれていますが、実際の XAML では別の場所でタグの対応が崩れている可能性が高いです。（解説：これでエラーが出ていると書いていてもこの回答となっています。また「可能性が高い」と言ってますが、すべてのコードが提示されているのですが。）

✔ 2. XAML ファイルのエンコードが UTF‑8 ではない
Visual Studio が何らかの理由で XAML を Shift‑JIS で保存してしまうと、日本語部分で「無効な文字」と判定されます。
対処
Visual Studio で
[ファイル] → [名前を付けて保存] → [保存] ボタン横の ▼ → [エンコード付きで保存] → UTF‑8
で保存し直すと直ることがあります。
（解説：この問題でした。オリジナルのコードがShift-JISであったので、それを張り付けてShift-JISのままにしていましたが、「xamlファイルはUTF-8エンコード以外は絶対に受け付けない」という「ネット社会の常識」が私になかったためでした。ただしCopilotは何も書きませんが、Visual Studioで「名前を付けて保存」、エンコーディングを"Shift-JIS"を"UTF-8"に変えただけでは完全にエンコーディングが変わらない現象を経験しています。私はメモ帳を使ってエンコーディングを変えてやっと「BOM付UTF-8」に完全変更しました。またアルファベットを使っている限りShift-JISでもUTF-8と互換なので問題は生じません。いまだに私のApplication.xamlはShift-JISのままです。念の為、Wpf_Calc.xamlファイルは「貼り付け」を"Paste"に変えています。）

✔ 3. 「貼り付け」の前後に不可視文字が混入している
コピー＆ペースト時に
- ゼロ幅スペース
- Unicode 制御文字
が混ざると XML パーサがエラーを出します。
一度「貼り付け」を削除して、手で打ち直すと改善することがあります。

✅ 正常に動く最小コード（検証済み）
<TextBox x:Name="formulaBox"
Height="128"
TextWrapping="Wrap"
Text="This is the formulaBox"
Width="240"
Margin="10,10,10,5"
IsReadOnly="True">
<TextBox.ContextMenu>
<ContextMenu Name="menu">
<MenuItem Header="貼り付け"
Name="pasteitemr"
Click="Clipboard_GetText"/>
</ContextMenu>
</TextBox.ContextMenu>
</TextBox>

これは WPF で問題なくコンパイルできます。（解説：これを張り付けても症状は変わりませんでした。原因特定が間違っていたからです。）

🎯 結論
- 日本語「貼り付け」は問題なし（解説：xamlファイルはUTF-8しか受け付けない（そんなことは知らなかったのですが）のに、Shift-JISで漢字を使ったのでエラーが出ただけのことでした。正しい対処は単に「貼り付け」を"Paste"にするか、エンコーディングを「メモ帳等Visual Studio以外を使って」保存し直すか、のいずれかでした。（どうも他のプログラムファイルのエンコーディングに合わす等、自動処理が働くようです。）
- エラーの原因は XAML の別の場所の構造崩れか（解説：これは全くありませんでした。何故コードがあるのにこの問題を提起しているのか、理解に苦しみます。）
ファイルのエンコード不一致
- 特に <TextBox.ContextMenu> の閉じタグや不可視文字に注意

もし可能なら、該当 XAML のもう少し広い範囲を貼ってくれれば、
どこが壊れているか正確に特定できるよ。（解説：「？」と感じませんか？）

いかがだったでしょうか？

Copilot君のエラー分析能力という点で、今回の話は「？」という印象をぬぐい切れません。原因は「指定されたエンコードに無効な文字があります。行 13」と「XAML ファイルのエンコードが UTF‑8 ではない」と動かないことに無知であったことでしたが、「構文が正しいならエンコーディングの点をもっと可能性のあるエラー原因と判断すべき」ではなかったでしょうか？

What do you think?

次回はもっと面白い話題がでてきますよ。お楽しみに。

【Visual Studio探検記】WPF電卓－コーディング（１）

酔狂で始めたWPF電卓（Wpf_Calc）作成、前回はUI（要すればドンガラ）迄何とかできました。後はWin_Calcで使ったコードを移植するだけで

完成

のはずでしたが、

陥穽

に陥ることになりました。その数々の中から今日は

「TextBoxに『貼り付け』だけのコンテキストメニューを作る」

という問題で「アセンブリ参照が不足しています」（注）というエラーが出た問題を取り上げます。

注：先ず「アセンブリ」とは（to make a long story short）実行可能なexeやdllファイルを言います。Windowsの共通言語ランタイム（CLR）は、様々な機能をDLLから呼び出して使います。その為にプログラムでは"using"（「名前空間（アセンブリ）」を指定する）ステートメントが必要で、リンクの際に当該DLLを「参照」することが必要です。

以下は私とCopilot（まぁ、Microsoftの使い魔でMSを擁護する立場にありますね）との対話ですが、貴方は

どう思われるでしょうか？(What do you thnk?)

【Copilotとの対話】

Q: 今度はWPFに電卓プログラムを移植するための質問です。 UIにTextBoxを追加し、コンテキストメニューを書き換えようとしたのですが、次のXAMLコードで、
<TextBox x:Name="formulaBox" Height="128" TextWrapping="Wrap" Text="This is the formulaBox" Width="240" Margin="10,10,10,5" IsEnabled="False">
<TextBox.ContextMenu>
<ContextMenu Name="menu" Opened="menuPaste">
<MenuItem Header="貼り付け" Name="pasteitemr" Click="Clipboard_GetText" />
</ContextMenu>
</TextBox>
アセンブリ参照不足エラーが出ました。何を参照すべきでしょうか？

A: WPF では、この程度の XAML を書いただけで「アセンブリ参照が不足しています」というエラーが出るのは、ほぼ 100% イベントハンドラの型が見つからないことが原因です。
つまり、参照すべきアセンブリが足りないのではなく、Opened="menuPaste" や Click="Clipboard_GetText" に対応するメソッドがコードビハインドに存在しないため（解説：なんでそれで「アセンブリ（解説：dllやexeファイルのこと）参照が不足しています」というエラー表示になるのか？訳が分からない。）に起きています。

🔍 なぜ「アセンブリ参照不足」になるのか
WPF の XAML パーサは、イベント名を見つけると
- その名前のメソッドが
同じクラスのコードビハインド（.xaml.cs）に存在するか
- そのメソッドのシグネチャが正しいか（解説：個人の記事ですが、定義の厳密性について言及しているので．．．）
をチェックします。
存在しない場合、Visual Studio は「アセンブリ参照が不足しています」という、少し（解説：大きく、だろう？）誤解を招くエラーを出します。

✅ 必要な（解説：アッセンブリの）参照は「特にない」
TextBox、ContextMenu、MenuItem はすべて
- PresentationFramework.dll
- PresentationCore.dll
- WindowsBase.dll
に含まれており、WPF プロジェクトなら最初から参照済みです。なので、追加のアセンブリ参照は不要です。（解説：何のためのエラー表示なんだ？大体エラーメッセージと矛盾していないか？）

🛠 解決方法：コードビハインドにイベントハンドラを追加する
1. Opened="menuPaste" に対応するメソッド
private void menuPaste(object sender, RoutedEventArgs e)
{
// 必要なら処理を書く
}

2. Click="Clipboard_GetText" に対応するメソッド
private void Clipboard_GetText(object sender, RoutedEventArgs e)
{
if (Clipboard.ContainsText())
{
formulaBox.Text = Clipboard.GetText();
}
}

✨ まとめ
- エラーの原因はイベントハンドラがコードビハインドに存在しないこと
- 追加のアセンブリ参照は不要

WPF は WinForms や Win32 と違って、XAML とコードビハインドの紐付けが厳密なので、こういう「参照不足」風のエラーが出やすいんですよね。もし次に進める段階でまた引っかかりそうなら、遠慮なく聞いてください。

Q: ありがとう。WPFは初めてなので初歩的質問をするかもしれませんが、よろしく。

A: もちろん、いくらでも気軽に聞いてほしい。WPF は Win32 や WinForms と比べて「思想」がまったく違うので、最初は誰でも戸惑うものなんだよね。むしろ初歩的なところを押さえておくと後が圧倒的に楽になる。
WPF の特徴をざっくり挙げると、こんな感じになる。
🎨 WPF の世界観は「UI とロジックの分離」
- XAML で UI を宣言的に書く
- C# でロジックを書く
- Win32 のように「コードで全部作る」必要はない
- WinForms のように「プロパティをいじるだけ」でもない
この「宣言とロジックの分離」が慣れるまで少し違和感があるけれど、理解すると一気に楽になる。
🧩 イベントの扱いが WinForms と微妙に違う
- XAML に Click="..." と書くと、コードビハインドに同名メソッドが必須
- シグネチャが違うと「アセンブリ参照不足」みたいな謎エラーになる
→ さっきの現象はまさにこれ
Win32/WinForms の感覚だと「イベント名を書いたら勝手に補完される」けれど、WPF はそこがシビア。
🔧 （私の名）さんのスタイルに合う WPF の学び方
あなたの「Lean and Mean」な開発スタイルを考えると、WPF でも次の順番が最も効率的だと思う。
- XAML の基本構造（Window / Grid / StackPanel）
- イベントの書き方（XAML とコードビハインドの紐付け）
- 依存関係プロパティの概念（Win32 のプロパティとは別物）
- バインディングの基礎（ここを押さえると一気に楽になる）
- 必要なところだけ MVVM を取り入れる（全部やる必要はない）
WPF は深追いすると底なしだけど、必要な部分だけ押さえれば十分に使いこなせる。

これから電卓を移植していく中で、
「Win32 ではこうだったけど、WPF ではどう書くのか」
という疑問が必ず出てくるはず。
そういう時こそ、遠慮なく聞いてほしい。
（私の名）さんのスタイルに合わせて、最短距離で理解できるように案内するよ。

どうでしょうか？この後の記事でも出てきますが、Visual Studioのエラーメッセージが非常に分かり辛い（というか、的を得ていない）という問題提起を先ずしておきます。

ps. ところでCopilot君の口調、何か感じませんか？

【Visual Studio探検記】WPF電卓－UIから

前回書いた通り、WinFormsベースのWin_Calc

でお終いにし、総括しようかと考えていた際に、「取り敢えず、WPFでデスクトッププロジェクトだけでも作ってみよう」ということで、いつもの”Class_Calc"ソリューションのプロジェクトとして"Wpf_Calc"を作ってみました。（↓参照）

構成の内、上から

（１）（Roslynが使うシステム間の）依存関係

（２）単に実行ファイルを作るだけのApp.xamlとApp.xaml.cs

「App.xaml」

<Application x:Class="Wpf_Calc.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:Wpf_Calc"
StartupUri="Wpf_Calc.xaml">
<Application.Resources>
</Application.Resources>
</Application>
「App.xaml.cs」

using System.Configuration;
using System.Data;
using System.Windows;

namespace Wpf_Calc
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
}
}

（３）そしてAssemblyInfo（WPF.icoというアイコンファイルが登録されていますね）

迄は、普通ユーザーは触らないので無視しましょう。ユーザーが直接関与するファイルは最後の二つだけです。

（４）Wpf_Calc.xamlファイルとWpf_Calc.xaml.cs（完成版のものを末尾に参考として載せておきます。）

です。（解説：ファイル名の通り、*.xamlファイルと*.xaml.csファイルは「対」の関係にある点に注意してください。）

（１）先ず私が最初に行ったのは、勝手につけられたMainWindow.xamlとMainWindow.xaml.csという名前や他のID名を「自分色の名前（それもありますが、Win_Calcと共通にする為）」に変えることでした。

そして

（２）次に行ったのは（私が苦手としていたxamlによる）UIデザインでした。ただ、今回は「無から生み出す」のではなく、「Win_CalcからWpf_Calcへ移植」という明確な目的（大義）があったので、前回で引用した過去のWPFプログラミング経験（即ち、「WPFウィンドウは一つのコンテンツしか持てないので、複数のコントロールを収容できるコンテナを配置し、その中にコントロールを配置する」）を踏まえ、

（１）先ずウィンドウデザインを定義する（サイズ変更可も検討しましたが、やはり縦長矩形の「電卓型」にしました。）

（２）次にコンテナ（WrapPanelにしました）を定義する

（３）そしてコントロール（TextBox、ListBoxとCanvasにし、Canvasの中にButtonを張り付けています）をコンテナに配置する

とトップダウン（全体→細部）で"Wpf_Calc.xaml"の（あまりWYSWYG的でない）デザイン画面とツールボックスを使い、（特にButtonコントロールは）ドロップダウン＋コードのコピペで大枠を固めてゆきました。xamlも所詮はコードなので、慣れれば（コード入力得意の私には）却って効率的に感じられるほどでしたが、やはり複雑なデザインは素人には難しいかもしれません。

（解説：上からWrapPanelに入ったTextBox、ListBox及びCanvasと、その中に入った19個のButton。Win_Calcと同じ風景にしました。）

いずれにせよ、（絵心のない私にも）何とかこの程度のものはxamlで作ることができました。後は張り付けたコントロール等に係る"Code-Behind"を移植するだけです。（解説：以下のコードにもコメントで書いていますが、私が躓いた数々のトリックや陥穽について、またCopilotとのやり取りで紹介するつもりです。）

【参考－完成版Wpf_Calc.xaml】

（解説：以下のxamlコードの内、緑字はWinFormsより便利になった部分、赤字はイベント関連部です。）

<Window x:Name="WpfCalc1" x:Class="Wpf_Calc.WpfCalc"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:Wpf_Calc"
mc:Ignorable="d"
Title="Wpf_Calc" Height="520" Width="295" ResizeMode="NoResize" TextInput="WpfCalc_KeyPress1" KeyDown="WpfCalc_KeyPress2">
<WrapPanel HorizontalAlignment="Left" Height="480" VerticalAlignment="Center" Width="260" Margin="10,10,10,10">
<TextBox x:Name="formulaBox" Height="128" TextWrapping="Wrap" Text="" Width="240" Margin="10,10,10,5" IsReadOnly="True" ToolTip="ここに演算式を表示します。"> （解説：ツールヒントを簡単に書けます。）
<TextBox.ContextMenu>
<ContextMenu Name="menu"> （解説：右クリックで出すコンテキストメニューも簡単に書けます。）
<MenuItem Header="Paste" Name="pasteitem" Click="Clipboard_GetText"/>
</ContextMenu>
</TextBox.ContextMenu>
</TextBox>

<ListBox x:Name="resultBox" Height="128" Width="240" d:ItemsSource="{d:SampleData ItemCount=5}" Margin="10,5,10,5" ToolTip="ここに演算式の解を表示します。解をダブルクリックすると演算式に追加されます。" MouseDoubleClick="resultBox_MouseDoubleClick"/>
<Canvas x:Name="keyPad" Height="194" Width="240" Margin="10,5,10,10">
<Button x:Name="button0" Content="0" Height="36" Canvas.Left="10" Canvas.Top="148" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button0_Click"/>
<Button x:Name="button1" Content="1" Height="36" Canvas.Left="10" Canvas.Top="102" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button1_Click"/>
<Button x:Name="button2" Content="2" Height="36" Canvas.Left="56" Canvas.Top="102" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button2_Click"/>
<Button x:Name="button3" Content="3" Height="36" Canvas.Left="102" Canvas.Top="102" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button3_Click"/>
<Button x:Name="button4" Content="4" Height="36" Canvas.Left="10" Canvas.Top="56" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button4_Click"/>
<Button x:Name="button5" Content="5" Height="36" Canvas.Left="56" Canvas.Top="56" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button5_Click"/>
<Button x:Name="button6" Content="6" Height="36" Canvas.Left="102" Canvas.Top="56" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button6_Click"/>
<Button x:Name="button7" Content="7" Height="36" Canvas.Left="10" Canvas.Top="10" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button7_Click"/>
<Button x:Name="button8" Content="8" Height="36" Canvas.Left="56" Canvas.Top="10" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button8_Click"/>
<Button x:Name="button9" Content="9" Height="36" Canvas.Left="102" Canvas.Top="10" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="button9_Click"/>
<Button x:Name="buttonLe" Content="(" Height="36" Canvas.Left="56" Canvas.Top="148" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonLe_Click"/>
<Button x:Name="buttonRe" Content=")" Height="36" Canvas.Left="102" Canvas.Top="148" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonRe_Click"/>
<Button x:Name="buttonPlus" Content="+" Height="36" Canvas.Left="148" Canvas.Top="10" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonPlus_Click"/>
<Button x:Name="buttonMinus" Content="-" Height="36" Canvas.Left="146" Canvas.Top="56" Width="36" HorizontalAlignment="Left" VerticalAlignment="Center" Click="buttonMinus_Click"/>
<Button x:Name="buttonMult" Content="*" Height="36" Canvas.Left="148" Canvas.Top="102" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonMult_Click"/>
<Button x:Name="buttonDiv" Content="/" Height="36" Canvas.Left="148" Canvas.Top="148" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonDiv_Click"/>
<Button x:Name="buttonBs" Content="BS" Height="36" Canvas.Left="194" Canvas.Top="10" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonBs_Click"/>
<Button x:Name="buttonCe" Content="CE" Height="36" Canvas.Left="194" Canvas.Top="56" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonCe_Click"/>
<Button x:Name="buttonEq" Content="=" Height="82" Canvas.Left="194" Canvas.Top="102" Width="36" HorizontalAlignment="Center" VerticalAlignment="Center" Click="buttonEq_Click"/>
</Canvas>
</WrapPanel>
</Window>

【参考－完成版Wpf_Calc.xaml.cs】

using Calc_Int; //解説：これが整数四則演算式を計算して解を返す自作DLLです。参照する必要があります。
using System.ComponentModel;
using System.IO;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using System.Windows.Automation.Peers; //buttonのPerformClick()の代わりに必要
using System.Windows.Automation.Provider; //buttonのPerformClick()の代わりに必要

namespace Wpf_Calc
{
/// <summary>
/// Interaction logic for WpfCalc.xaml
/// </summary>
public partial class WpfCalc : Window
{
//メンバーフィールド
string formulaStr = ""; //（formulaBoxの）四則演算式文字列
bool calcEnd = false; //計算終了フラグ
List<string> calcLog = new List<string>(); //計算ログ用リスト
string logPath; //このアッセンブリーへのパス

public WpfCalc()
{
InitializeComponent(); //解説：ここでxamlプログラムでUIを実装します。
//計算ログ用フォールダーの確認と存在しない場合の作成（解説：基本Win_Calcと同じです）
logPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location) + "\\Calc_Log";
if (!Directory.Exists(logPath))
Directory.CreateDirectory(logPath);
}

//終了時処理
protected override void OnClosing(CancelEventArgs e) //解説：WinFormsではOnClosed。微妙に名前が違います。
{
base.OnClosing(e);
if (calcLog.Count > 0) //計算歴があれば
{
//(WinFormns)DialogResult dr = MessageBox.Show("計算ログを保存しますか？", "確認", MessageBoxButtons.YesNo, MessageBoxIcon.Question);
MessageBoxResult dr = MessageBox.Show("計算ログを保存しますか？", "確認", MessageBoxButton.YesNo, MessageBoxImage.Question); //解説：WinFormsと微妙に違います。
if (dr == MessageBoxResult.Yes) //(WinFormns)DialogResul.Yes と微妙に違います。
{
//計算ログの保存（解説：WinFormsとと同じです。
string fn = logPath + "\\CalcLog_" + DateTime.Now.ToString("yyyyMMdd_HHmmss") + ".txt";
using (StreamWriter sw = new StreamWriter(fn, false, Encoding.Default))
{
foreach (string str in calcLog)
{
sw.WriteLine(str);
}
}
}
}
}

//クリップボードに取り込んだ文字列を張り付ける（解説：WinFormsではDesigner.csに書かれていましたが、WPFではここにメソッドを定義します。）
private void Clipboard_GetText(object sender, RoutedEventArgs e)
{
if (Clipboard.ContainsText())
{
formulaStr = formulaBox.Text = Clipboard.GetText();
}
}

private void WpfCalc_KeyPress1(object sender, TextCompositionEventArgs e)
{   //解説：WinFormsのKeyPressイベントはWPFになく、"TextInput"イベントを使います。（間違えやすいので注意）
IInvokeProvider provider;   //解説：WinFormsのButton.PerformClickと同様の処理のために必要です。
switch (e.Text) //WPFではe.KeyCharの代わりにe.Textとなる
{
//WPFではchar '0'～'9''の代わりにstring "0"～"9"を使う
case "0":
  //解説：WinFormsのbutton0.PerformClick();の代わりとなる2行です。（以下同じ）
provider = new ButtonAutomationPeer(button0) as IInvokeProvider;
provider.Invoke();
break;
case "1":
//button1.PerformClick();
provider = new ButtonAutomationPeer(button1) as IInvokeProvider;
provider.Invoke();
break;
case "2":
//button2.PerformClick();
provider = new ButtonAutomationPeer(button2) as IInvokeProvider;
provider.Invoke();
break;
case "3":
//button3.PerformClick();
provider = new ButtonAutomationPeer(button3) as IInvokeProvider;
provider.Invoke();
break;
case "4":
// button4.PerformClick();
provider = new ButtonAutomationPeer(button4) as IInvokeProvider;
provider.Invoke();
break;
case "5":
//button5.PerformClick();
provider = new ButtonAutomationPeer(button5) as IInvokeProvider;
provider.Invoke();
break;
case "6":
//button6.PerformClick();
provider = new ButtonAutomationPeer(button6) as IInvokeProvider;
provider.Invoke();
break;
case "7":
//button7.PerformClick();
provider = new ButtonAutomationPeer(button7) as IInvokeProvider;
provider.Invoke();
break;
case "8":
//button8.PerformClick();
provider = new ButtonAutomationPeer(button8) as IInvokeProvider;
provider.Invoke();
break;
case "9":
//button9.PerformClick();
provider = new ButtonAutomationPeer(button9) as IInvokeProvider;
provider.Invoke();
break;
   case "(":
//buttonLe.PerformClick();
provider = new ButtonAutomationPeer(buttonLe) as IInvokeProvider;
provider.Invoke();
break;
case ")":
//buttonRe.PerformClick();
provider = new ButtonAutomationPeer(buttonRe) as IInvokeProvider;
provider.Invoke();
break;
case "+":
//buttonPlus.PerformClick();
provider = new ButtonAutomationPeer(buttonPlus) as IInvokeProvider;
provider.Invoke();
break;
case "-":
//buttonMinus.PerformClick();
provider = new ButtonAutomationPeer(buttonMinus) as IInvokeProvider;
provider.Invoke();
break;
case "*":
//buttonMult.PerformClick();
provider = new ButtonAutomationPeer(buttonMult) as IInvokeProvider;
provider.Invoke();
break;
case "/":
//buttonDiv.PerformClick();
provider = new ButtonAutomationPeer(buttonDiv) as IInvokeProvider;
provider.Invoke();
break;
case "=":
//buttonEq.PerformClick();
provider = new ButtonAutomationPeer(buttonEq) as IInvokeProvider;
provider.Invoke();
break;
default:
break;
}
}

private void WpfCalc_KeyPress2(object sender, KeyEventArgs e)
{   //解説：WinFormsnoKeyPressでは拾えたBSが拾えないので、WPFのKeyDownで補完して拾います。
IInvokeProvider provider;   //解説：Button.PerformClickの代替処理の為必要。
switch (e.Key) //WPFではe.KeyCharの代わりにe.Keyとなる（解説：Keyは列挙型。）
{
case Key.Delete:
// buttonCe.PerformClick();相当のものDelキーでを新設する（解説：お遊びで追加しました。）
provider = new ButtonAutomationPeer(buttonCe) as IInvokeProvider;
provider.Invoke();
break;
case Key.Back:
// buttonBs.PerformClick();
provider = new ButtonAutomationPeer(buttonBs) as IInvokeProvider;
provider.Invoke();
break;
default:
break;
}
}

//ボタン共通処理（解説：これはボタン共通部分を抽出した自作メソッドです。WinFormsと同じです。）
private void button_Click(string s)
{
//計算終了後にボタンが押された場合、formulaBoxをクリアする
if (calcEnd)
{
formulaBox.Text = formulaStr = "";
calcEnd = false;
}
formulaStr = (formulaBox.Text += s);
}

private void button0_Click(object sender, RoutedEventArgs e)
{
button_Click("0");
}

private void button1_Click(object sender, RoutedEventArgs e)
{
button_Click("1");
}

private void button2_Click(object sender, RoutedEventArgs e)
{
button_Click("2");
}

private void button3_Click(object sender, RoutedEventArgs e)
{
button_Click("3");
}

private void button4_Click(object sender, RoutedEventArgs e)
{
button_Click("4");
}

private void button5_Click(object sender, RoutedEventArgs e)
{
button_Click("5");
}

private void button6_Click(object sender, RoutedEventArgs e)
{
button_Click("6");
}

private void button7_Click(object sender, RoutedEventArgs e)
{
button_Click("7");
}

private void button8_Click(object sender, RoutedEventArgs e)
{
button_Click("8");
}

private void button9_Click(object sender, RoutedEventArgs e)
{
button_Click("9");
}

private void buttonLe_Click(object sender, RoutedEventArgs e)
{
button_Click("(");
}

private void buttonRe_Click(object sender, RoutedEventArgs e)
{
button_Click(")");
}

private void buttonPlus_Click(object sender, RoutedEventArgs e)
{
button_Click("+");
}

private void buttonMinus_Click(object sender, RoutedEventArgs e)
{
button_Click("-");
}

private void buttonMult_Click(object sender, RoutedEventArgs e)
{
button_Click("*");
}

private void buttonDiv_Click(object sender, RoutedEventArgs e)
{
button_Click("/");
}

private void buttonBs_Click(object sender, RoutedEventArgs e)
{
if (!string.IsNullOrEmpty(formulaBox.Text))
{
formulaStr = (formulaBox.Text.Remove(formulaBox.Text.Length - 1));
formulaBox.Text = formulaStr; //再表示
}
}

private void buttonCe_Click(object sender, RoutedEventArgs e)
{
formulaStr = "";
formulaBox.Text = formulaStr; //再表示
}

private void buttonEq_Click(object sender, RoutedEventArgs e)
{
//formulaBoxの文字列を取得して、計算する
if (!string.IsNullOrEmpty(formulaStr))
{
try //解説：計算式が間違っていた場合にエラー落ちすると格好が悪いので．．．
{
Calc calc = new Calc(formulaStr);
int sol = 0;
calc.TryCalc(ref sol); //計算式にエラーがあった場合、以下の例外で検知する
resultBox.Items.Add(sol.ToString());
calcLog.Add(formulaStr + "=" + sol.ToString()); //計算ログ用リストに追加
calcEnd = true; //解説：次に計算式入力があった場合、先ずテキストボックスをクリアする
}
catch (Exception excptn) //解説：メッセージボックスでエラーを表示させる形にしました。
{
//WinFormsではMessageBox.Show(excptn.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
MessageBox.Show(excptn.Message, "Error", MessageBoxButton.OK, MessageBoxImage.Error);
}
}
}

private void resultBox_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
if (resultBox.SelectedItem != null)
button_Click(resultBox.SelectedItem.ToString());
else
//WinFormsではMessageBox.Show(excptn.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
MessageBox.Show("No item is selected", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
}
}

【Visual Studio探検記】WPF電卓

前に「【告知】しばらくお休み || 手抜きします」なんて書きましたが、結局神様が全て片付け、私は娘の育児支援に関して戦力外通告をされてブログを書き続けることができました。（泣笑）

そゆことで．．．【Visual Studio探検記】を続けます。

さて、何とか前回でC# + WinFormsベースの電卓が完成しました。

Visual Studioのダウンロード、インストール、"Hello、world!"を表示するコンソールプログラム、ウィンドウプログラム、コンソールプログラムによる速度比較、C++用自作ライブラリー（ECCSkelton）の使用、そしてC#（WinFormsベース）による原初的な「電卓」アプリ開発と進めてきました（接続詞）

switch（接続詞）

{

case "ので": //解説：もともとはこのように考えていました。

Console.WriteLine("いよいよVisual Studio 2026の総括へと進みたいと思います。");

break;

case "が": //解説：しかし、徒然なるままにWPFをいじっているうちに、このように考え始めました。

Console.WriteLine("XAML等マークアップ言語に疎く、気が進まなかったのですが、Visual Studio 2026の総括へと進む前に、C#と.NET用のもう一つのプラットフォームであるWPF（Windows Presentation Foundation）で「電卓」をこさえてみようかと思います。");

break;

default:

Console.WriteLine("今のところその他の選択肢は考えていません。");

break;

}

と、

C#プログラム風に書いてみたのは、将に「//解説：」コメント通りの心境の変化があったからです。

WPFは所謂「MVVM（Model-View-ViewModel）」志向で、UIをXAMLでデザイナーが作成し、それに連携するプログラムコードは"Code-Behind"としてプログラマーが書くという、将にVisual Studioの流れそのものの開発体制にフィットするプラットフォームですので、「個人で何でもやって、趣味のプログラムを書く」人（要すれば私のような人）には全く向いていない開発環境です。（注）

注：初めてWPFと遭遇した時の研究記事です。結構ツボを押さえていると思います。

【WPF】まずは結論から．．．、

【WPF】発端．．．（１）、【WPF】発端．．．（２）、

【WPF】WPFを学習する（１）、【WPF】WPFを学習する（２）、

【WPF】Window vs Formで検証、

【WPF】ところで．．．ウィンドウコントロールからコンテンツへ、

【WPF】サンプルでContentを検証、

【WPF】複数のコントロールは？、【WPF】複数コントロールの前に．．．、【WPF】複数コントロールを使うには．．．、【WPF】複数コントロールのサンプルで遊んでみる．．．ご興味がある方はその後のWPFのコントロールやMediaElement、MediaPlayerの記事もご参照願います。

しっかし、

【Visual Studio探検記】と名打ってWPFのアプリに触れないのは余りに低レベル且つ不親切だと思い返し、

「電卓くらいなら、まっ、いいか？」

と思い直した次第。それにプログラムの