- PR -

InitializeComponent 内に自動生成されるコントロールの順序について

«前のページへ 1|2
投稿者投稿内容
ｉＳｔａｔｉｏｎ
大ベテラン
会議室デビュー日: 2003/12/08
投稿数: 158
投稿日時: 2005-01-11 10:13
順序が変更されては困る部分を、InitializeComponent() の外に出す
実装をしてはいかがですか？
_________________
IEEE-CSDP 2004-2007
こばさん
大ベテラン
会議室デビュー日: 2004/03/17
投稿数: 147
投稿日時: 2005-01-11 11:12
引用:

順序が変更されては困る部分を、InitializeComponent() の外に出す
実装をしてはいかがですか？


　ありがとうございます。
　データ連結後のグリッドの列の見栄え（デザイン）をデザイナ上で行いたい（標準でスキーマ読み書きしている模様）と思ってます。
　InitializeComponentの外に出すと、コーディング量が増え、かつ保守性（効率性）が下がるんで・・・

　<DebuggerStepThrough> を外してステップ実行してみたら、ISupportInitialize.BeginInit 〜 ISupportInitialize.EndInit に囲まれているにも関わらず、FlexGrid の DataSource に DataSet への参照をセットした時点で、FlexGrid が DataSet に対して Fill を要求しているのが分かりました。

　私の認識では、正しくインプリメントされたコントロールであれば、ISupportInitialize.BeginInit 〜 ISupportInitialize.EndInit の間ではイベントを発生させない（ISupportInitialize.EndInitが呼ばれた時点で処理する）という風であるべき、だと思ってたんですが、そもそもその認識が間違ってますでしょうか？
（コントロールがベストな状態にインプリメントされていないだけ？）

　<System.Diagnostics.・・・> のような、ソースコードに埋め込んでコントロールの初期化順序を制御を IDE に対して指定することができればなぁと思ってたんですが。

　予断ですが、この辺でデバッグ＆検証作業をしていると、自前でコントロールを作る際に留意しておくべきことが分かってきますね。
ｉＳｔａｔｉｏｎ
大ベテラン
会議室デビュー日: 2003/12/08
投稿数: 158
投稿日時: 2005-01-11 11:56
引用:

こばさんさんの書き込み (2005-01-11 11:12) より:
引用:

順序が変更されては困る部分を、InitializeComponent() の外に出す
実装をしてはいかがですか？

　ありがとうございます。
　データ連結後のグリッドの列の見栄え（デザイン）をデザイナ上で行いたい（標準でスキーマ読み書きしている模様）と思ってます。
　InitializeComponentの外に出すと、コーディング量が増え、かつ保守性（効率性）が下がるんで・・・

DataSetの生成部分を、コンストラクタ内のInitializeComponent()の前に出せばよいと思います。
クラス化すれば保守性も向上！
なお、コントロールのところはInitializeComponentの外に出す必要はないですが...
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-01-11 21:41
引用:

こばさんさんの書き込み（2005-01-11 09:44）より：

　IDE が自動生成したコードの話なんですが。。。
（私がコード書かずに）

　中さんのコメントは『コンストラクタで変なことしてるからそんなことになるんですよね？ 』ですよね。このコードはコンストラクタではなく、『IDE が自動生成したコード』ですよね。・・・あ、『ISupportInitialize.BeginInit 〜 ISupportInitialize.EndInit の間ではイベントを発生させない（ISupportInitialize.EndInitが呼ばれた時点で処理する）という風であるべき』（2005-01-11 11:12）につながるのか。

　最初に読んだときから疑問なのですが。。。
引用:

（2005-01-09 10:53）より：

　FormB を色々といじっていると、InitializeComponent 内でコントロールの初期化するところの順序が変わってしまいます。
　InitializeComponent 内のコードが、ControlB → ControlA の順序に変わってしまうのです。
　
　継承元である FormA は ControlA → ControlB の順序のままです。

FormBはFormAを継承しているんですよね。ここで「コントロール初期化の順番が変わる」のは、FormB.InitializeComponentメソッドでしょうか？それともFormA.InitializeComponentメソッドでしょうか？私的には、FormB.InitializeComponentメソッドに、FormA上にあるコントロールの初期化がコーディングされるというのが納得できないのですが。ちなみに、手元のプロジェクトでForm1を継承してForm2を作成しましたが、Form2のInitializeComponentメソッドの中は
コード:
private void InitializeComponent()
{
	this.components = new System.ComponentModel.Container();
	this.Size = new System.Drawing.Size(300,300);
	this.Text = "Form2";
}

だけです。Form2、Form1の継承先では、Form1上のコントロールのプロパティを変更するコード、オブジェクトを生成するコードは記述されていません。
　FormAのInitializeComponentはFormAのコンストラクタから呼び出されますが、それはFormBのコンストラクタから、FormBのコンストラクタ実行前に呼び出されます。FormAのコントロールをProtectedアクセスに宣言したとしても、作成はFormBコンストラクタの実行前に実行されています。また、コントロールの生成はFormA上で行われます。そうでなければ、FormBからアクセスできません。プロパティの変更はできても、コントロールの作成をFormB.InitializeComponentメソッドで行うのはおかしいと思いますし、そういうコードがFormB.InitializeComponentメソッドに書かれることはないと思います。アクセス権の設定やバインドのさせ方などを含めて、『コンストラクタで変なことしてる』のではないでしょうか。

　まず、FormAで宣言しているコントロールとそのアクセス権、FormBで宣言しているコントロールおよびそのコントロールとFormAで宣言されているコントロールとの関係を洗い直す必要があるのではないでしょうか。

　そして、これまでに書かれている内容からは、「FormA上に配置したコントロールが、FormB上でオブジェクト化され、その順番が何かの拍子に入れ替わる」という問題であると理解しています。
　もし、問題となっているコードがFormB独自のものであるなら、「FormAを継承している」というのが問題に関係しているのか、切り分ける必要があると思います。

_________________
こばさん
大ベテラン
会議室デビュー日: 2004/03/17
投稿数: 147
投稿日時: 2005-01-13 10:19
引用:

　そして、これまでに書かれている内容からは、「FormA上に配置したコントロールが、FormB上でオブジェクト化され、その順番が何かの拍子に入れ替わる」という問題であると理解しています。
　もし、問題となっているコードがFormB独自のものであるなら、「FormAを継承している」というのが問題に関係しているのか、切り分ける必要があると思います。


　色々とありがとうございました。
　継承していないコントロールでも、コントロール連携で不穏な動作を発見しました。
　コントロール間の依存関係をうまく処理せずに IDE がコード生成しているせいなのか、はたまたコード生成順序に依存してしまっているコントロールの作りが悪いのか、判りませんが。。。

　時間ができたら、ユーザーコントロールでラップして、変な手間（IDEが生成したコーディングの順序を入れ替える）が発生しないようにしたいなぁとは思ってます。

　ところで、BeginInit〜EndInitで括ってるにも拘らず「コード生成順序に依存してしまっている」というのは、仕様なんでしょうかね？それともバグなんでしょうかね？
　再現手順が明確になれば、コントロールの製造元にサポート依頼いるんですが。。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）