| ■6643 / inTopicNo.3) | Re[1]: 別ウインドウ(スレッド)からコントロール操作(デリゲート) |
| 少々誤解があるようです。 お示しになったコードにはスレッド成分が含まれていません、よね？ スレッド越しのコントロールの操作にデリゲートが使用される（ことが多い）のは事実ですが、デリゲート自体はスレッドとは無関係で、飽くまで処理の委譲のためのものです。 一般に、複数のウィンドウがあってもそれらは同一のスレッドで動作させます。新しくフォームを表示したら自動的に別スレッドが立ち上がってということはありません。 と言うことで、話は単純にオブジェクト間の処理の主体の話になります。 今回は子フォームが親フォームに処理の実装を委譲する形ですね。 さて、子フォームの処理をご覧ください。 委譲するための親フォームをどうやって取得していますか？ new してますよね。このキーワードは、文字通り「新しい」インスタンスを作成するためのものです。 新しく作られたものですから、既にあるものとは別物です。つまり、既に表示中の親フォームとは別物なのです。 別物のフォームなので、それが何をどうしようと既に表示中の親フォームには何の影響も及ぼせません。 子フォームが既存の親フォームに処理を委譲するなら、なんとかして既存の親フォームを取得する必要があります。 例えば子フォームに親フォーム型のプロパティを持たせ、子フォームを表示するときに親フォームが自身を設定するといった方法が考えられます。 んが、それ以前にこういうコードは望ましくありません。以前に書いてたと言うコンストラクタでデリゲート渡す方がよほどマシです。 そもそも、子フォームが親フォームの呼び出すべきメソッドを知っているなら、デリゲートの出番はないですよね？ 直接そのメソッドを呼び出せばいいんですから。 m_callbackSetText1( textBox1.Text ); よりも fp.SetTextBox1( textBox1.Text ); の方が直感的でしょう。 デリゲートが意味を持つのは、そのデリゲートに関連付けられたメソッドを知らない状況です。 ですから何を関連付けるか（つまりデリゲートを作成すること）は親フォームの仕事です。 // 端的に言えば、「子は親を知っているべきではない」ってことになるんですが……まあ省略。 ところで、デリゲートを使った仕組みの一つにイベントがあります。コントロールのクリックイベントとかです。 今回の目指すところが「子フォームに親フォームテキストを設定してもらうこと」ではなく「何か子フォームに変化があったことを親フォームに教えたい（親フォームの TextBox が変更されるのはその結果）」ということなら、イベントを使った方がいいでしょう。 |