Q&A
何を作っているのでしょうか？ VB.NET で作るものは Windows Forms, WPF, ASP.NET Web Forms などいろいろあって、それによって答えが違ってくると思うのですが・・・ あと、自分の開発環境（OS, .NET, Visual Studio のバージョンなど）もきちんと書きませんか。質問するときのイロハのイです。
初めて質問をさせていただきます。
作成しているもの：Windows フォーム アプリケーション
- 開発環境
OS: Windows 10 64bit
.NET Framework: Version 4.7.02053
開発ツール: Visual Studio Community 2017 (Version 15.3.0)
質問内容はタイトルの通りなのですが、VB.netの画面で全く同じ部品を使ったヘッダーやフッターがある画面がいくつもあった場合、フォームの継承を使っても問題ないのでしょうか？
例えば、ボタンが全く同じ位置にあるが、押下時の処理は全く別のことをするときなど。
継承は「is-a」関係でないといけないといった話を聞いたことがあるので、同じ部品があるからといって継承を使ってもいいのかと悩んでいます。
他の方はどのように考えるのか知りたいので、よろしければ回答をお願いいたします
2017/11/08 15:47 追記
Windows Forms アプリということですと「複数の画面」というのは複数の Form で、どれも似たような内容になっている。なので、すべてに共通の部分を洗い出して基になる Form を一つ作り、それを継承して必要に応じてカスタマイズするということですか？
そういうことになります。
でも、今提供されている情報だけでは絶対に問題ないとは言い切れないです。もう少し具体な例を出せませんか。
すべてのFormで共通の部分(具体的になっているかはわからないですが)
- Formのサイズが 700 x 660
- Form内の上の方にラベルが1つ配置されている(表示内容はそれぞれのFormによって異なる)
- Form内の下の方にボタンが8つ配置されている(ボタン押下時の処理はそれぞれのFormによって異なる)
となっています。また、中央部分はそれぞれのFormでばらばらの部品が配置されている。
質問内容へのご指摘、ありがとうございます。修正致します。
Windows Forms アプリということですと「複数の画面」というのは複数の Form で、どれも似たような内容になっている。なので、すべてに共通の部分を洗い出して基になる Form を一つ作り、それを継承して必要に応じてカスタマイズするということですか？ であれば、自分的には何の問題もなさそうに思えるのですが・・・ でも、今提供されている情報だけでは絶対に問題ないとは言い切れないです。もう少し具体な例を出せませんか。
追記いたしました。お聞きしたいのですが、Formのクラスでも、「子クラスをさらに継承した子クラスを作成(デザインの階層を作るという考え方)」しても問題はありませんでしょうか？
回答3件
0
•Form内の上の方にラベルが1つ配置されている(表示内容はそれぞれのFormによって異なる)
•Form内の下の方にボタンが8つ配置されている(ボタン押下時の処理はそれぞれのFormによって異なる)
となっています。また、中央部分はそれぞれのFormでばらばらの部品が配置されている
そういうことでしたら、すみませんが、上のコメント欄の私のコメント「問題なさそう」は撤回させてください。デザイン画面上で、中央部分の部品を配置というのは無理っぽいです。
カスタムコントロールを作るということもメリットはあまりなさそうだと個人的には思います。ハンドラのアタッチをどうするのかとか悩みが多そうな割には、あまり汎用的ではなさそうで、それを考えて解決するのに見合う開発工数の削減はなさそうな気がします。
メリット/デメリットを天秤にかけて考えると、普通に Form を継承した Form1, Form2 ... を Visual Studio の機能を利用して追加し、それに直接上記の操作をした方が良いのではないでしょうか。
投稿2017/11/08 09:46
退会済みユーザー
総合スコア0
回答ありがとうございます。
子画面で新たにコントロールを追加するのは難しいということですね...また、カスタムコントロール(ユーザーコントロール?)については自分で調べてみます。
> 普通に Form を継承した Form1, Form2 ... を Visual Studio の機能を利用して追加し
というのは下記のような手順で問題ないでしょうか。
プロジェクト > 新しい項目の追加 > Windows Forms > 継承されたフォーム を選択し、追加ボタンを押下。継承ピッカーウィンドウで親クラスを選択し、OKボタンを押下。
申し訳ございません、「上記の操作」とはどのような作業でしょうか...
質問者さんの言われる「継承されたフォーム」というのは以下の記事で紹介されているものですよね？
独自Windowsフォーム・クラスの活用
http://www.atmarkit.co.jp/fdotnet/chushin/introwinform_11/introwinform_11_01.html
自分が言うのは From を継承する「Windows フォーム」のことで、それにゼロからドラッグ＆ドロップで必要なコントロール類を追加していく（それが「上記の操作」という意味です）ということを提案させていただきました。
もちろん、「継承されたフォーム」の追加で質問者さんの望むことがより簡単にできるのであれば、それに越したことはないと思いますが。
継承されたフォーム とはそちらのサイトのようなことを考えておりました。
「Windows フォーム にゼロからドラッグ＆ドロップで必要なコントロール類を追加していく」という作成の仕方を行っていくことにします。
ありがとうございました！助かりました！
0
Formの継承は難しいと思います。
Formの継承は、Designer.vbファイルをエディタ等で手動で修正する必要があります。
また、Formには、個別のリソース.resxファイルあり、これがうまく継承できません。
一般に、Formのコントロールを共通化するには、ユーザーコントロールを用います。
プロジェクトに、ユーザーコントロールを追加し、それに共通のコントロールを配置し、処理を記述したものを、それぞれのフォームに貼り付けます。
投稿2017/11/08 08:37
総合スコア243
回答ありがとうございます。
Formの継承は難しいということで了解しました。Formのデザインについて継承が難しいということでしょうか。
> Formの継承は、Designer.vbファイルをエディタ等で手動で修正する必要があります。
これは、Formを継承した時点での「親クラスのデザイン(サイズ等)が子クラスのデザインに継承される」ということがある(?)ため、手動で修正する必要があるという解釈でよろしいでしょうか。
また、自分でFormの継承を試してみた結果、「親クラスのデザイン(サイズ等)が子クラスのデザインに継承される」といったことがわかりました。その時のFormの継承は以下の手順で行いました。
プロジェクト > 新しい項目の追加 > Windows Forms > 継承されたフォーム を選択し、追加ボタンを押下。継承ピッカーウィンドウで親クラスを選択し、OKボタンを押下。
ユーザーコントロールについては調べてみて、使ってみようと思います。
0
「継承されたフォーム」を使ってもいいのではないでしょうか。
（他の回答では否定的なようですが、私が何か前提を読み間違えているのかな？）
手順
- ベースとなるフォーム（サイズが700x660、上部にラベルx1、下部にボタンx8）を作成する（仮に
BaseFormクラスとします） BaseFormクラスに必要なプロパティやメソッドを追加する- いったんビルドする
- フォームを追加する際に「新しい項目の追加」ダイアログで「Windows フォーム」ではなく「継承されたフォーム」を選択する
- 「継承ピッカー」ダイアログで
BaseFormを選択して「OK」を押す - 追加したフォームをデザイナーで編集したりプロパティやメソッドを実装したりする
手順2. について
BaseForm を継承したフォームで使われそうなプロパティ（上部ラベルに表示するテキスト、下部ボタン達に表示するテキスト、あたり？）は BaseForm のプロパティにしておきます。
また、下部ボタンを押したときのイベントハンドラーをオーバーライド可能にしておきます。
vb
1' ラベル LabelTitle と ボタン Button1～Button8 がある想定 2' このクラス自体は「プロジェクト > 新しい項目の追加 > Windows Forms > Windows フォーム」として追加する 3Public Class BaseForm 4 5 ''' <summary>フォーム上部のラベルに表示する文字列</summary> 6 Public Property FormTitle As String 7 Get 8 Return LabelTitle.Text 9 End Get 10 Set(value As String) 11 LabelTitle.Text = value 12 End Set 13 End Property 14 15 ''' <summary>下部ボタン1個目に表示する文字列</summary> 16 Public Property Button1Text As String 17 Get 18 Return Button1.Text 19 End Get 20 Set(value As String) 21 Button1.Text = value 22 End Set 23 End Property 24 ' 以下、Button8Textまで同様に追加する 25 26 ''' <summary>下部ボタン1個目を押したときの処理</summary> 27 Protected Overridable Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click 28 ' Button1押下時の共通処理があれば、ここに追加する 29 End Sub 30 ' 以下、Button8_Clickまで同様に追加する（要Overridable） 31 32End Class
手順6. について
手順2. で実装したプロパティを、デザイナーあるいはコードから適宜変更します。
また、下部ボタンを押したときのイベントハンドラーをオーバーライドします。
vb
1' FormTitle や Button1Text などはデザイナーから変更する想定 2Public Class NewForm1 3 4 Protected Overrides Sub Button1_Click(sender As Object, e As EventArgs) 5 MyBase.Button1_Click(sender, e) 6 7 ' 個別の処理をここに追加する 8 End Sub 9 10End Class
うまく設計すれば、Formを継承して共通ラベルやボタンを1個ずつ配置するよりも楽になるかと思います。
複数人で開発する場合は特に。
投稿2017/11/09 02:25
総合スコア2019
> 他の回答では否定的なようですが、私が何か前提を読み間違えているのかな？
私の回答が誤解を招く書き方だったようですみません。
ポイントは回答に書きました「メリット/デメリットを天秤にかけて考える」です。
その先は自分の勝手な想像ですが、どうもデメリットの方が重そうと思いました。
alg さんが書かれた具体例で言うと、(1)「継承されたフォーム」を使うために必要な「手順2. について」や「手順6. について」に書かれたことを実装・試験するための工数と、(2)「継承されたフォーム」を使うことによって削減できる開発工数（間違いなどによる後戻り工数も削減できるであろうとは思います）とを比べて、どっちが重そうかということを考えて判断するという話になると思います。
「Form内の下の方にボタンが8つ配置されている」ということなどから、あまり汎用性はなさそうで、(2) より (1) の方が重そうだと勝手に思った次第です。
回答ありがとうございます。
ソースコードの記載、ありがとうございます。
早速、試してみました。これであれば、活用できそうな気がします。
一つだけ、気になったのですが、BaseForm の Size を「700x500」に変更した時に、NewForm1 の Size が自動的に「700x500」にならないのは仕方ないのでしょうか。そうした場合には、デザイナー等で変更する方法でしか対処出来ないのでしょうか。
リビルドもしくは Visual Studio から実行（変更されていれば自動的にリビルドされるはず）すれば変更が反映されませんか？
あなたの回答
tips
プレビュー
