- - PR -
別フォームを利用した処理について
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-28 23:04
質問ではないのですが、意見をお伺いしたく登校しました。
シナリオは以下のようなものです。 --------------------------------------------------- グラフを表示している親フォームから、子フォームを表示する。 子フォームで親フォームのグラフのプロパティを設定し「設定」ボタンをクリックすると、設定が適用され、子フォームはクローズする *子フォームは、引数なしのshow()で表示する. *子フォームが閉じられるのは「設定」ボタンクリックのみ --------------------------------------------------- 子フォームがスレッド外で起動するため、設定を適用するタイミングとして以下があると思います。 1.「設定」ボタンクリック時に起動されるデリゲートを使用する。 2.子フォームのClosingやClosed で処理する。 皆さんならどちら(もしくはその他にあれば教えてください[busy loopはなしで。])でしょうか? 個人的には、「設定」をクリックしたから設定するのであって、フォームが閉じたから設定するわけではないという意味を大切にして、コーディング量が増えても1で処理したいのですが。。。。。 以上よろしくお願いします。 | ||||||||||||
|
投稿日時: 2008-05-28 23:35
その子フォームが表示されている間、親フォームが操作可能であることが必要なのでしょうか? もし、親フォームを操作する必要がないのであれば、ShowDialogでモーダル表示にする方が楽で良いかと思います。
単純にShowしただけでは、同じスレッドです。 「スレッド外で起動する」という考えは誤りです。
ちょっとシナリオがまとまっていない感じがします。 A.モーダル表示である&設定あるいはキャンセルで子フォームが閉じる ShowDialogの戻り値でOKかCancelが得られるようにしておき、OKであれば子フォームのプロパティを通じて、設定値を反映する。 (OpenFileDialogやSaveFileDialogと似たようなイメージ) B.モードレス表示である&設定あるいはキャンセルで子フォームが閉じる 設定ボタンやキャンセルボタンが押されたことを意味するイベントを子フォームが公開し、親フォーム側でそのイベントにイベントハンドラ(デリゲート)を割り当てて処理するかなぁ。 C.モードレス表示である&設定を押しても子フォームは閉じない(=適用ボタンのようなイメージ) 設定ボタンのイベントを公開するという意味で、Bと同様ですね。 | ||||||||||||
|
投稿日時: 2008-05-28 23:39
基本的には、理に適っていることをやるのが一番です。 例えば、設定ボタンクリック時はサブフォームを閉じないという仕様変更が発生した時のことや、キャンセルボタンも用意するという仕様変更が発生した時のことを考えれば、自ずと 2 は除外されます。理に適っていないことをやると、たいてい脆さが現れます。 ただし、それがいつでも正しいかというと、そんなことはありません。複雑さが増すとかコーディング量が多くなるといったデメリットがある場合、メリットとデメリットを天秤にかけることも必要です。(今回のケースはたぶんコーディング量も変わらないのでは?) 要はコンテキスト次第ということです。 _________________ C#と諸々 [ メッセージ編集済み 編集者: よこけん 編集日時 2008-05-28 23:41 ] | ||||||||||||
|
投稿日時: 2008-05-29 23:46
Azulean様:
言葉足らずで、申し訳ありませんでした。 ・モーダレスで表示 ・ダイアログの表示処理は別スレッドで行う。 以上は、仕様です。
私の意図したところとしては、Bでしょうか。 ただ、イベントやらデリゲートを使用するほどのことなのかなぁという気にさせられるわけですが。。 | ||||||||||||
|
投稿日時: 2008-05-29 23:57
よこけん様
そのとおりだと思います。 キャンセルボタンなどが増えた際にDialogResultのようなもので、何が原因でフォームが閉じられたかを管理することもできましょうが、自然じゃないですよね。 実際にはもう少し複雑な部分があったりして、コード量が増えるのは事実なのですが、メリットとデメリットを考えて対処したいと思います。 (理にかなってないことを選択しなくてはいけないというストレスはデメリットにいれる) 皆さんありがとうございました。 | ||||||||||||
|
投稿日時: 2008-05-30 14:24
私も「1.」が良いと思います。 フォームがモーダルでもモードレスでも使えますし、また、フォームではなくコンポーネントの場合でも共通して使えます。「1.」に統一しておけばフォームかどうかを気にせずに使えます。 | ||||||||||||
|
投稿日時: 2008-05-30 15:00
どういう意図でそのようにしているのかは分かりませんが、今のシナリオ(フォーム同士が通信する気まんまん)で、UI スレッドを分割するのは良い設計とは言えないと思いますよ。 どういう意図で UI スレッドを分割してます? UI スレッドを分割してたら 1 でも 2 でもかなりやりにくくないですか? _________________ 囚人のジレンマな日々 | ||||||||||||
|
投稿日時: 2008-05-30 22:25
本当に別スレッドで出しているのですか? 別スレッドになるために必要な要素: ・Threadクラス ・ThreadPoolクラス ・BackgroundWorkerコンポーネント ・デリゲートのBeginInvokeメソッド? これらの要素のいずれも使っていない場合は別スレッドになっていないと推測されます。(Showメソッドでスレッドが分かれるという誤解の可能性を疑ったもの) また、現状の情報ではモードレスで表示するだけで、スレッドを分ける必要を感じません。
イベント等で親フォームに通知しないと、親フォームは押されたことが分かりませんよね? モーダル・モードレス・別スレッドのどんな手法であれ、ボタンが押されることでイベントが発生します。それに繋げる要素をイベントにするか、デリゲートにするか、メッセージにするかの違いかと思います。 |