.NET の Form.OwnedForms は、「親となるフォームが所有している子フォームの一覧を取得するための読み取り専用プロパティ」です。2026年7月1日に公開・更新された公式情報を確認するうえでの結論は、新しい設定変更や強制移行が必要な変更ではなく、複数ウィンドウ構成の WinForms アプリで、所有関係・閉じる動作・MDI との違いを正しく見直すことが重要という点です。
特に影響を受けやすいのは、検索ウィンドウ、置換ウィンドウ、ツールパレット、補助ダイアログなどをメインフォームに紐づけて表示している .NET Windows Forms アプリです。OwnedForms を使うと、所有されているフォームをまとめて取得し、タイトル変更、状態確認、終了処理、表示制御などを一括で行えます。ただし、MDI 子フォームを取得する用途には向いていないため、MDI アプリでは MdiChildren との使い分けが必要です。Microsoft Learn でも、OwnedForms は「このフォームが所有するすべての Form オブジェクトの配列を取得する」と説明されています。(Microsoft Learn)
.NET の Form.OwnedForms Property とは
Form.OwnedForms は、System.Windows.Forms.Form クラスに用意されているプロパティです。名前空間は System.Windows.Forms、アセンブリは System.Windows.Forms.dll です。公式リファレンスでは、プロパティの型は Form[] で、[Browsable(false)] が付与された読み取り専用プロパティとして示されています。(Microsoft Learn)
public System.Windows.Forms.Form[] OwnedForms { get; }このプロパティで取得できるのは、「現在のフォームが所有しているフォーム」の配列です。ここでいう所有とは、単にフォームから別のフォームを生成したという意味ではありません。AddOwnedForm メソッドを呼び出すか、対象フォームの Owner プロパティに所有者フォームを設定した場合に成立する関係です。(Microsoft Learn)
たとえば、メイン画面から検索用の小さなウィンドウを表示する場合、検索ウィンドウをメイン画面の owned form にしておくと、メイン画面が最小化されたときに検索ウィンドウも隠れ、メイン画面の背後に回り込まないようにできます。これは、一般的な業務アプリの「補助ウィンドウ」を扱うときに便利です。
2026年7月1日更新情報で確認すべきポイント
今回の Form.OwnedForms Property に関する公式情報は、API の基本仕様を再確認する内容として見るのが適切です。少なくとも公式リファレンス上、OwnedForms 自体について、アプリ全体の挙動を変える新しい設定項目や、管理者が期限付きで対応しなければならない移行要件は示されていません。
実務上の確認ポイントは、次のとおりです。
| 確認項目 | 内容 | 実務での見直しポイント |
|---|---|---|
| API の役割 | 所有されているフォームの配列を取得する | 補助ウィンドウの一覧取得に使っているか |
| 変更の性質 | 設定変更ではなく API 仕様の確認 | アプリ設定やレジストリ変更は通常不要 |
| 影響範囲 | Windows Forms の複数フォーム構成 | 検索画面、置換画面、ツール画面、サブ画面 |
| MDI との違い | MDI 子フォームは OwnedForms の対象外として扱う | MDI アプリでは MdiChildren を使う |
| 移行期限 | OwnedForms 単体の期限は示されていない | .NET バージョンのサポート期限を別途確認 |
ポイントは、OwnedForms を「フォームを全部取れる便利な一覧」と雑に扱わないことです。取得できるのは、あくまで 所有関係にあるフォーム です。単に new Form() で作成して Show() しただけのフォームや、MDI 子フォームをまとめて取得する目的では、期待どおりに動かない可能性があります。
OwnedForms が効く仕組み：AddOwnedForm と Owner の関係
OwnedForms にフォームを含めるには、所有関係を明示する必要があります。代表的な方法は2つです。
// 方法1: 所有者フォーム側から追加する
this.AddOwnedForm(searchForm);
searchForm.Show();// 方法2: 所有されるフォーム側に Owner を設定する
searchForm.Owner = this;
searchForm.Show();公式ドキュメントでは、フォームを別フォームの owned form にするには AddOwnedForm を呼び出す方法と、Owner プロパティに所有者フォームへの参照を設定する方法が説明されています。また、owned form は RemoveOwnedForm が呼び出されるまで所有された状態のままです。(Microsoft Learn)
所有関係を解除する場合は、RemoveOwnedForm を使います。公式情報では、RemoveOwnedForm は owned form の一覧からフォームを削除し、対象フォームの owner も null に設定すると説明されています。(Microsoft Learn)
this.RemoveOwnedForm(searchForm);
searchForm.Close();実務では、フォームを閉じる前に必ず RemoveOwnedForm が必要というわけではありません。ただし、長時間起動する業務アプリで補助ウィンドウを何度も生成・破棄する場合は、所有関係、イベント購読、参照保持が残っていないかを確認することが重要です。
OwnedForms を使う典型的な活用シーン
OwnedForms が役立つのは、メインフォームに付随する補助ウィンドウをまとめて扱いたい場面です。
たとえば、次のような画面構成では有効です。
| 活用シーン | OwnedForms を使う理由 |
|---|---|
| 検索・置換ウィンドウ | メイン画面の背後に隠れないようにできる |
| ツールパレット | メイン画面と一緒に最小化・非表示にしやすい |
| プレビューウィンドウ | メイン画面に従属する補助画面として管理しやすい |
| 設定サブ画面 | メイン画面終了時にまとめて閉じられる |
| デバッグ用の状態表示画面 | 開いている補助画面を一括更新できる |
公式リファレンスでも、owned form は所有者フォームが閉じられたり最小化されたりすると、それに合わせて閉じられる、または非表示になると説明されています。さらに、owned form は所有者フォームの背後には表示されないため、検索や置換のようにメインフォームの後ろへ隠れてほしくないウィンドウに向いています。(Microsoft Learn)
実装例：所有フォームを追加して一覧を操作する
次の例では、メインフォームから検索ウィンドウを owned form として表示し、OwnedForms でまとめてタイトルを更新します。
private void ShowSearchWindow()
{
var searchForm = new Form
{
Text = "検索ウィンドウ"
};
this.AddOwnedForm(searchForm);
searchForm.Show();
}
private void RenameOwnedForms()
{
for (int i = 0; i < this.OwnedForms.Length; i++)
{
this.OwnedForms[i].Text = $"補助ウィンドウ {i + 1}";
}
}このコードのポイントは、Show() の前に AddOwnedForm() を呼び出していることです。OwnedForms は読み取り専用プロパティなので、配列に直接フォームを追加するのではなく、所有関係の設定には AddOwnedForm または Owner を使います。
また、実務コードでは同じ種類のフォームを重複して開かないようにする処理もよく使います。
private void ShowSearchWindowOnce()
{
foreach (Form owned in this.OwnedForms)
{
if (owned.Name == "SearchForm")
{
owned.Activate();
return;
}
}
var searchForm = new Form
{
Name = "SearchForm",
Text = "検索"
};
this.AddOwnedForm(searchForm);
searchForm.Show();
}このようにすると、検索ウィンドウがすでに開いている場合は新規作成せず、既存のウィンドウを前面に出せます。業務アプリでは、同じ補助画面が複数開いてユーザーが混乱するケースを防げます。
MDI アプリでは OwnedForms と MdiChildren を混同しない
OwnedForms で最も注意したいのが、MDI との使い分けです。
Microsoft Learn では、フォームが MDI 親フォームの場合、OwnedForms は現在開いている MDI 子フォームを除外し、MDI 親フォーム内で開かれた MDI 子フォームを取得するには MdiChildren を使うと説明されています。(Microsoft Learn)
つまり、次のように考えると分かりやすいです。
| 取得したい対象 | 使うプロパティ |
|---|---|
| メインフォームが所有する検索・置換・ツール画面 | OwnedForms |
| MDI 親フォーム内に開いている文書ウィンドウ | MdiChildren |
| 子フォーム側から所有者フォームを知りたい | Owner |
| owned form を登録したい | AddOwnedForm |
| owned form の所有関係を解除したい | RemoveOwnedForm |
MDI アプリで「開いている子画面を全部保存してから閉じる」という処理を書く場合、OwnedForms を使うと対象がずれる可能性があります。この場合は MdiChildren を使い、文書フォームや業務入力フォームをループ処理するべきです。
private void SaveAllMdiChildren()
{
foreach (Form child in this.MdiChildren)
{
// MDI 子フォームの保存処理
}
}一方で、MDI 親フォームに付随する検索ウィンドウやツールウィンドウを管理するなら、OwnedForms のほうが適しています。MDI 子フォームと補助ウィンドウは、UI 上はどちらも「子画面」に見えることがありますが、WinForms の内部的な関係は異なります。
影響範囲：どのアプリが確認すべきか
Form.OwnedForms の確認が必要なのは、すべての .NET アプリではありません。対象は Windows Forms を使ったデスクトップアプリです。特に、複数フォームを扱う既存アプリ、.NET Framework から .NET へ移行するアプリ、MDI 構成を含む業務アプリでは確認する価値があります。
| 対象 | 確認の優先度 | 理由 |
|---|---|---|
| 単一フォームだけの小規模アプリ | 低 | OwnedForms を使う場面が少ない |
| 検索・設定・プレビュー画面を別フォームで出すアプリ | 高 | 所有関係の有無で表示順や終了動作が変わる |
| MDI を使う業務アプリ | 高 | OwnedForms と MdiChildren の混同が起きやすい |
| .NET Framework から .NET へ移行中の WinForms アプリ | 中〜高 | 移行時にフォーム管理の設計を見直す機会になる |
| ASP.NET、MAUI、WPF のみのアプリ | 原則対象外 | System.Windows.Forms.Form の API ではない |
Windows Forms は .NET の UI 技術であり、Microsoft のドキュメントでは Windows Forms アプリを .NET Framework から .NET へアップグレードする際の考慮点も整理されています。特に、Windows デスクトップアプリは .NET 上でも Windows 専用であること、ターゲットフレームワークの更新、破壊的変更、NuGet 依存関係の確認が重要とされています。(Microsoft Learn)
設定変更は必要か
Form.OwnedForms 自体に関して、管理者がテナント設定、OS 設定、レジストリ、アプリ構成ファイルを変更しなければならない内容はありません。
ただし、次のようなコード上の見直しは必要になる場合があります。
| 見直し対象 | 問題になりやすい例 | 対応 |
|---|---|---|
| 所有関係の設定漏れ | new Form().Show() だけで表示している | AddOwnedForm または Owner を設定する |
| フォームの重複表示 | ボタンを押すたびに同じ補助画面が増える | OwnedForms で既存画面を探して再利用する |
| 終了処理 | メイン終了時に補助画面が残る | 所有関係を設定し、必要に応じて明示的に閉じる |
| MDI 子フォーム取得 | OwnedForms で MDI 子フォームを処理しようとする | MdiChildren に切り替える |
| 参照保持 | 閉じたフォームへの参照が残る | FormClosed で参照解除する |
特に移行プロジェクトでは、単にビルドを通すだけでなく、「フォームの所有関係が期待どおりか」を画面操作で検証することが重要です。UI の問題はコンパイルエラーとして出ないことが多く、実際に最小化、前面表示、閉じる操作を試さないと発見しにくいためです。
移行期限はあるか
Form.OwnedForms プロパティ単体に、特定日までの移行期限は示されていません。したがって、OwnedForms を使っているからといって、ただちにコード変更やリリース対応が必要になるわけではありません。
一方で、アプリが動作している .NET バージョンにはサポート期限があります。Microsoft の .NET サポートポリシーでは、.NET 10 は LTS として 2028年11月14日まで、.NET 9 は 2026年11月10日まで、.NET 8 も 2026年11月10日までのサポートとされています。また、サポート期間中も最新パッチを適用していることが重要です。(Microsoft)
管理者や開発リーダーは、OwnedForms の変更だけを見るのではなく、次の順番で確認すると実務的です。
| 確認順 | 内容 |
|---|---|
| 1 | アプリが Windows Forms を使っているか |
| 2 | 複数フォーム、補助ウィンドウ、MDI を使っているか |
| 3 | OwnedForms、Owner、AddOwnedForm、RemoveOwnedForm の利用箇所があるか |
| 4 | MDI 子フォーム取得に OwnedForms を誤用していないか |
| 5 | 利用中の .NET バージョンがサポート期間内か |
| 6 | .NET Framework から .NET への移行予定があるか |
この流れで確認すれば、API の仕様確認とライフサイクル管理を分けて整理できます。
管理者・開発チームが確認すべきチェックリスト
Form.OwnedForms に関して、開発チームやアプリ管理者が確認すべき項目は次のとおりです。
コード確認
// OwnedForms の利用箇所を検索
OwnedForms
// 所有関係の設定箇所を検索
AddOwnedForm
Owner =
// 所有関係の解除箇所を検索
RemoveOwnedForm
// MDI 利用箇所を検索
MdiChildren
MdiParent
IsMdiContainer検索後は、次の観点でレビューします。
| チェック項目 | 判断基準 |
|---|---|
OwnedForms を MDI 子フォーム取得に使っていないか | MDI 子フォームなら MdiChildren を使う |
| 補助ウィンドウに所有者が設定されているか | メインフォームに従属すべき画面なら設定する |
| 閉じる処理が二重になっていないか | owner の終了時と個別 close の競合を確認する |
| 既存フォームの再利用ができているか | 同じ検索画面を何枚も開かない |
Owner の型を前提にしすぎていないか | 必要に応じて安全にキャストする |
動作確認
実機またはテスト環境では、次の操作を確認します。
| 操作 | 期待する結果 |
|---|---|
| メインフォームを最小化する | owned form も隠れる、または最小化に追従する |
| メインフォームを閉じる | owned form が残らない |
| メインフォームを選択する | owned form が背後に回り込まない |
| 補助ウィンドウを複数回開く | 重複表示が意図どおり制御される |
| MDI 子フォームを開く | OwnedForms ではなく MdiChildren で取得できる |
UI の自動テストがある場合でも、ウィンドウの前後関係や最小化時の動作は自動化しにくいことがあります。重要な業務画面では、手動テストの観点として明示しておくと安全です。
よくある失敗と回避策
OwnedForms にフォームが入っていない
new Form() で作成して Show() しただけでは、所有関係は設定されません。
var toolForm = new Form();
toolForm.Show();この場合、this.OwnedForms に toolForm が含まれない可能性があります。メインフォームに従属させたいなら、次のようにします。
var toolForm = new Form();
this.AddOwnedForm(toolForm);
toolForm.Show();または、次のように Owner を設定します。
var toolForm = new Form
{
Owner = this
};
toolForm.Show();MDI 子フォームを OwnedForms で処理してしまう
MDI アプリでは、文書ウィンドウや入力画面を MDI 子フォームとして開くことがあります。この一覧を処理するなら、OwnedForms ではなく MdiChildren を使います。
foreach (Form child in this.MdiChildren)
{
// MDI 子フォームの処理
}OwnedForms は、MDI 子フォームではなく、所有関係にある補助フォームを扱うものと考えると誤用を避けやすくなります。
Owner を具体的なフォーム型として直接扱ってしまう
子フォーム側から所有者フォームにアクセスしたい場合、Owner は Form 型として取得されます。メインフォーム固有のメソッドやプロパティを使いたい場合は、安全にキャストします。
if (this.Owner is MainForm mainForm)
{
mainForm.RefreshSearchResult();
}ただし、子フォームが親フォームの具体型に依存しすぎると再利用性が下がります。頻繁に値をやり取りするなら、イベント、インターフェイス、引数渡しなどを検討したほうが保守しやすくなります。
.NET Framework から .NET へ移行する場合の見方
OwnedForms は Windows Forms の基本的なフォーム管理 API であり、移行時に真っ先に置き換えるべき API というより、画面遷移やウィンドウ管理の棚卸しで確認すべき API です。
.NET Framework から .NET へ移行する場合、Microsoft の移行ガイドでは、プロジェクト形式、利用できない API、依存ライブラリ、破壊的変更などの確認が必要とされています。Windows Forms は .NET でもサポートされ、High-DPI やアクセシビリティなどの改善も継続されていますが、Windows デスクトップアプリは引き続き Windows 専用です。(Microsoft Learn)
移行時には、次のように整理すると効率的です。
| 移行時の観点 | 確認内容 |
|---|---|
| 画面構成 | メインフォーム、補助フォーム、MDI 子フォームを分類する |
| 所有関係 | 補助フォームに Owner または AddOwnedForm が設定されているか |
| ライフサイクル | メイン終了時に補助フォームが残らないか |
| 表示順 | 検索・置換画面が背後に隠れないか |
| テスト | 最小化、復元、閉じる、再表示を確認する |
.NET 10 の Windows Forms では、非同期フォーム、ダークモード、クリップボード関連などの改善も示されていますが、OwnedForms の理解はそれらの新機能とは別に、複数ウィンドウアプリの基本設計として押さえておくべき内容です。(Microsoft Learn)
次に取るべき対応
Form.OwnedForms Property について、今回の確認で最も重要なのは、設定変更や期限対応ではなく、自社アプリのフォーム所有関係が意図どおりに設計されているかを確認することです。
まずはコードベースで OwnedForms、AddOwnedForm、RemoveOwnedForm、Owner、MdiChildren を検索してください。次に、補助ウィンドウと MDI 子フォームを分類し、誤ったプロパティで一覧取得していないかを確認します。最後に、メインフォームの最小化、終了、再表示、補助ウィンドウの重複表示を実際に操作して検証します。
OwnedForms は目立つ新機能ではありませんが、複数ウィンドウの業務アプリではユーザー体験に直結します。検索画面が背後に隠れる、メイン画面を閉じても補助画面が残る、MDI 子フォームが保存対象から漏れるといった問題は、日常的な操作で信頼性を下げます。今回の公式情報をきっかけに、フォーム管理のコードを一度棚卸ししておくと、.NET のバージョン移行や Windows Forms アプリの保守が進めやすくなります。
コメント