Visual Basic 中学校 掲示板 投稿の管理
タグのない投稿を抽出
統計
RSS
Visual Basic 中学校
投稿一覧
2つのフォーム間でのユーザコントロールに対するアクセス
この投稿へのリンク
https://keijiban.umayadia.com/ThreadDetail.aspx?ThreadId=9086#CommentId11332
この投稿の削除
削除パスワード
削除する
コメント本文
投稿者
魔界の仮面弁士
 (社会人)
投稿日時
2009/4/22 19:32:24
元質問者とは、別の投稿者名に変わってしまっていますよ。
> この件ですが、別のフォームからアクセスするために、色の設定をプロパティーにて
> Public宣言して、外からアクセス出来るようにしたのですが、この点が、推奨できない
> との事でしょうか?
いえ、今回指摘したカプセル化の件は、uctRect を貼った「frmB クラス」に対するものです。
作成した「uctRect クラス」の設計については、概ね問題無いと思いますよ。
細かく言えば、プロパティ名が一般的な命名規約に沿っていないとか、
http://msdn.microsoft.com/ja-jp/library/cc433291.aspx
http://msdn.microsoft.com/ja-jp/library/ms229002.aspx
デザイナのための「規定値」の設定が不足しているとか、
http://msdn.microsoft.com/ja-jp/library/53b8022e.aspx
変更通知イベントが実装されていないといった点はありますけれどね。
http://msdn.microsoft.com/ja-jp/library/ms229016.aspx
> VB5にて、コントロール配列があり、2008にてコントロール配列への対応記事が載っていますが、
もしかして、VB5 の利用経験がおありなのでしょうか?
VB5 のコントロール配列は、名前に反して配列ではなく、コレクションの一種です。
普通は、Text1, Text2 で TextBox として管理されているコントロールが、
Text1(0), Text1(1) とインデックスで管理できるようになるという物ですね。
コントロール配列化した場合、Text1 は TextBox 型ではなく、このコレクション型に変化します。
Text1.Count で同名のコントロールを取得でき、イベント通知も個々の Text1(0) に対して受けるのでは無く、
コレクションである Text1 にて一括管理されるようになります(引数 Index で区別する)。
このコントロール配列は、旧バージョンとの互換性維持を目的として、
http://msdn.microsoft.com/ja-jp/library/microsoft.visualbasic.compatibility.vb6.textboxarray.aspx
などといった管理クラスが、それぞれのコントロールごとに用意されています。
しかし今回の場合、ここまで大げさな物を用意せずとも、
http://dobon.net/vb/dotnet/control/buttonarray.html
http://homepage1.nifty.com/rucio/main/shokyu/jugyou20.htm
などの方式で十分かと思います。
> プロジェクト毎に「カプセル化」?しなさいとのことですね。
はい。そしてカプセル化は、プロジェクト毎のみならず、クラス毎に対しても必要です。
(VB2008 に限らず、VB6、VB4、VBA、VBScript であっても同様です)
frmA をアプリケーション本体とした場合、そこから frmB のコントロールを操作したいというのは
比較的良くある話だと思います。たとえば、データ自体が frmA で管理されていて、それを
frmB たとえば「進捗表示画面」や「オプション設定画面」などに表示させる場合などには、
frmA から frmB のコントロールに、データを渡す必要があるでしょう。
しかしながら、今回のように
> frmB.uctRect0.shpLamp_BackColor = Color.Red
あるいは
> For i=0 to frmB.panel1.Controls.Count-1
のように、frmA が frmB のコントロールを直接操作してしまうと、フォーム間の結びつきが強くなりすぎてしまいます。
frmB のコントロールを変更したりすると、frmB の修正後に frmA まで修正せねばならなくなってしまいます。複数画面から frmB を利用していた場合は修正も大変です。
そこで、依存性排除のために、カプセル化という作業が必要になります。
カプセル化されたフォームの実装例を、たとえば「InputBox」などに見る事ができます。
これは TextBox や Button が配置されたフォームを表示する機能ですが、呼び出し側が、それらのコントロールを
frmInputBox.TextBox1.Text = "新しい値"
などと直接触るような設計にはなっていませんし、逆に InputBox 側がメインフォームを直接操作することもありません。
> N88Basicにて
正確には、大文字のみで N88-BASIC と記述します。そもそも BASIC という言語名自体が、
Beginner's
All-purpose
Symbolic
Instruction
Code
の略という事もあり、当時の BASIC 系言語の正式名称は、基本的にすべて大文字表記です。
小文字の混じる表記法が使われだしたのは、比較的後発の製品ですね。
("Visual Basic"、"ActiveBasic"、"REALbasic" 等)
# 私が小学生の頃は、OA-BASIC を使っていました。どうでも良い事ですが。
>> frmB の操作は frmB 自身に任せ、frmA は frmB に対して、背景色の
>> 「変更依頼」をメソッドあるいはイベントを通じて投げた方がよろしいかと。
> イベントで行う場合、「frmBにて70個の色データ領域(配列)を持っていて、そのデータのchange
> イベントで自分自身の色を変更する。一方、frmAは色データを変更する。」といった感じですか?
70個の色データを管理する役割が、frmA にあるのか frmB にあるのかそれ以外にあるのかは、
そのアプリの仕様に依存するところなので、私には判断ができません。しかし、その change イベントと
いうのが、データの変更を知らせるための独自イベントであるならば、たとえば frmB を
Private WithEvents manager As データ管理クラス
Private Sub manager_change(…) Handles manager.change
Me.Shapes(e.Index).shpLamp_BackColor = e.Color
End Sub
などと記述するイメージにできるかと思います。
データ管理クラスとは frmA で良いのか、引数 e の実装をどうするのかといった
細かい点は、実装したい元仕様によりますので、ケースバイケースですけれども。