dポイントプレゼントキャンペーン実施中!

私は度々、質問者の方が他のフォームのコントロールを直接操作するコード(Controlsプロパティ経由であったりアクセスレベルをpublicなどにしてあったり)書かれているのを見ると「(設計上の理由で)他フォームのコントロールを直接操作するのはお勧めしません」とアドバイスのつもりで書いてたりするのですが(毎度それを読まされてうんざりされてる方もいるかもしれませんが)、その「他のフォームのコントロールを直接操作するのはお勧めしない」ということはおかしい事でしょうか?
私は汎用性などを考え設計的な理由でそういってるわけで(理想をいえばモデルを用意することなんでしょうが、そこまでいうつもりはないです)、技術的理由でいってるわけじゃないです。

元ネタは
http://oshiete.goo.ne.jp/qa/7582043.html
なのですが正直相手にするのに疲れたので他の方の意見もお聞きしたいと思ったしだいです。

A 回答 (6件)

> オーナースレッドが同じなら他フォームのコントロールを直接操作しても問題はない。



確かに「例外要因にならない」って意味では問題ないでしょうが、オーナースレッドが同じ場合とそうでない場合で異なるコードを書くのは徒に混乱を招くだけなので、例外が発生する(=オーナースレッドが別である)ことを前提に書くのが普通でしょうねぇ。
フォームの可搬性とか以前の問題で、状況により例外が発生してしまうようなコードは基本的にNGでしょう。
#例外でトラップする以外にエラーチェックしようがないケースはもちろん除きますが
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

おっしゃるとおりオーナースレッドと同じかどうかで使い方が違うと混乱の元にしかならないですね。そんな場合分けで使い方を覚えたくもないですし。

お礼日時:2012/07/18 01:02

保守やプログラムの再利用を考えればクラス間はできるだけ疎結合になっている方が自明と思うけど、


コントロールを直接操作するなんていう密結合にするとは!
それらのフォームをセットとして考えているならそういう実装もありかもしれないけど。
    • good
    • 1
この回答へのお礼

回答ありがとうございます。
疎結合の方がユニットテストなどをする場合においても便利だと思うんですけどね。

お礼日時:2012/07/22 23:06

僕はもっと強く:「他に手がないほどの切羽詰まった状況でない限り、よそ様のコントロールを直接触らない(触らせない)」です。


# やりたいのは[印刷ボタンを押したい]んじゃなく、[印刷したい]のはず。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

私も自分でつくるプログラムだったり関わるプロジェクトに関してはそうしてます。

お礼日時:2012/07/16 15:44

フォームのオーナースレッド外からの変更は例外誘発要因なのでお勧めするしない以前の問題だと思うのですが、そーゆー事ではないのでしょう

か?
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

そういう事ではないみたいです。
先方の主張としては
オーナースレッドが同じなら他フォームのコントロールを直接操作しても問題はない。なのでその条件下では他フォームのコントロールを直接操作するのは当たり前の事。
技術的に問題があるわけでもないので「他フォームのコントロールを直接操作するのはお勧めしない」というのは意味がない。
という事みたいです。
私が誤読をしてなければですが。

お礼日時:2012/07/16 15:41

おかしいことを言っているとは思いませんよ.


こういうところの解答は,よくわかっていない人も解答しているから,
あまり気にしない方がいいと思います.

.NETになる前の,VB使いの人だと,
他のフォームのコントロールを直接操作したくなりそうな気がしますが,
まぁ,「とにかく動けばいいんだ」という人が居ても,
それはそれで,人それぞれの考えですから・・・

「一応のアドバイスはした」ということで,いいじゃないですか.
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

色々な方がいらっしゃるのはわかってますので自ら望んでやられてる方にまでいうつもりはないんですけどね。

お礼日時:2012/07/16 15:32

途中から質問者も出てこなくなったので放置していましたが……



回答しておいてアレですが、私はプロパティ経由でアクセス。で組んでいますね。
フオームのインスタンス生成して、プロパティで設定。
フォームの表示時にプロパティに応じてコントロールの設定。
フォームを閉じた後プロパティ経由で結果を受け取り…ってところです。

といってもC#はつい2ヶ月くらい前から必要に迫られて触り始めたのですが。
# 書籍2冊、あとはサイト見ながら…って程度のレベルです。
# C言語ならまぁそこそこ。C++は一応読める(けど設計まではできない)ってくらいで。
# カプセル化も考え方の意味は理解している(つもり)です。

プロパティ経由ならアクセサーで制限できたりしますし。
コントロールを直接だと設計がまずかった(命名がまずかった)などで変更される場合がありますし。
# まぁ、プロパティでもいまいちだったりすると名前変更することがありますが……。

privateとpublicは使い分けているつもりですが……少々怪しいと言わざるをえない状況です。
# まぁ基本的にprivateでフィールドとか作りますかね。他から使われても困るので。

Controlsプロパティは……自分のフォーム上のコントロールでまとめて無効/有効を切り替えるときに使うくらいでしょうか。
あんまりそういう機会が無いので使いませんが。
# いや、ホントは使う機会はあったんですけどね。有効に戻す部分が条件いろいろだったので諦めた(制限事項で逃げた)ので。

1つのアプリでユーザーが操作できるのはアクティブになっているフォーム1つ(アプリケーションモーダル)でしか使っていないから…でしょうけど。
モードレスになるとまた変わるんでしょうけどね……。
# C+Win32APIでもモードレスほとんどやったことないしなぁ。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

私もモーダルやフォーム2つくらいまでならプロパティで済ませてしまいそうな気はします。
さすがに多数のフォームのコントロール(の値)が相互に作用するとかになるとプロパティを使ってもコードは大変なことになっちゃいますけど。

お礼日時:2012/07/16 14:46

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!