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

http://bbs.wankuma.com/index.cgi?mode=al2&namber …

ここで紹介されているソースをさんこうにしていたのですが、

public event EventHandler TextBox1Changed;

が果たしている役割がよくわかりません。
これは何のためにあるのでしょうか?

たとえば、
http://dobon.net/vb/dotnet/vb2cs/event.html
コチラのサイトでは、
public event EventHandler Time;

System.Threading.Thread.Sleep(5000);
if (Time != null)
{
Time(this, EventArgs.Empty);
}
のように書かれていますが、いきなりif (Time != null)を記述してエラーがでないということは、Cのプロトタイプ宣言のような機能を有しているのでしょうか?

また、この例ではなにもしないので具体的な使い方もみえてこず、この次の例はすでに理解を超えていてさっぱりわかりません。

イベントハンドラはいったいどのような役割を担っているのでしょうか?

A 回答 (3件)

> 私の継承の認識が間違っているのかもしれません。


> 継承するつもりがなくてもForm2のオブジェクトをつくるためにインスタンスはするのでクラスの定義は必
> 要だと思うのですが、そういうことではないのでしょうか?


あってます。
私も、言葉の認識違いで混乱させてしまったかもと思った次第です・・・。
そういうことで大丈夫です。

リンクにあるコードを参考にすると、継承関係は以下のようになっていて、認識されている通りです。
Form2 <- Form

が、Form1の中のロジックで、Form2を利用していて、そこでイベントをプログラムによって
実装させています。(frm2.TextBox1Changed += frm2_TextBox1Changed;)
ここで、Form2で定義したイベントハンドラが効果を発揮していますね。

確かにこういうことを必要としないなら、イベントハンドラを定義する必要性はありません。


私が想定していたのはこの流れではなくて、継承関係が以下のようになっている場合です。
ExForm <- Form2 <- Form

この時、ExFormのイベントプロパティの一覧に、Form2で定義しているイベントハンドラが出現します。


どちらもやれることは同じです。

例えば私が過去に作ったプログラムの中では、テキストの変更を捕捉するイベントハンドラを用意しました。
TextChangedイベントは、テキスト内容が変更されてから走行します。
私が求めたものは、『テキストが変更される前に、何が入力されたかを検知し、入力値を許可・拒否する』というものです。
その為、TextChangingというイベントハンドラを用意することにより、そのテキストボックスコンポーネントを利用して開発を行う人は、TextChangingイベントを実装して入力値の許可・拒否を自在に拡張できるようにしました。

イベントハンドラは、そういう、コンポーネントの利用者が要件に応じて求めることが異なるはずですから、それを手助けしてあげてくれるものです。
そういった利用者拡張を必要としない場面ならば、イベントハンドラを定義する意味はあまりないのではないでしょうか。


フォームとして何か決まった処理をするけども、その処理の前と後に自由に制御入れてもいいよ、とか。
前処理のイベントでキャンセル制御が行われたら後続処理をしないようにしてあげよう、とか。
(TextBoxでいうValidating、Validatedイベントの関係性のような)
    • good
    • 0
この回答へのお礼

思ってたよりイベントハンドラが自由なものでした。
てっきり構造上の決まりで書かなければならない”おまじない”的なものなのかと思っていました。

マスターすればもっとプログラミングの視界が開けそうで楽しみです。

お礼日時:2014/04/04 19:21

> イベントハンドラは基本的に継承した後のことを意識して作る場合に必要なイメージを持ちました。


> ということは、クラスを定義して定義したクラスからインスタンスはおこなえど、継承をするつもりがな
> いのであればイベントハンドラは定義する必要のないものなのでしょうか?

んー、継承って、クラスのことですか?
継承するつもりがないということは、そもそもそのクラスを作る必要性も疑わしくなりませんか?


継承先で独自のイベントを実装するつもりがないということであれば、継承元でイベントハンドラを
実装する必要性はありません。
が、継承元を作成する人間・チーム(提供元)と、継承先を作成する人間・チーム(利用者)が
異なるようなら、実装する必要性があるかどうかは、実際にそのクラスを継承して利用する人々な
わけですから実際利用するかどうかは別にして、アプローチとして用意することはアリだと思います。
イベントハンドラを定義して独自のタイミングで発行することができるのは提供元だけですので。

この回答への補足

>>んー、継承って、クラスのことですか?
>>継承するつもりがないということは、そもそもそのクラスを作る必要性も疑わしくなりませんか?

私の継承の認識が間違っているのかもしれません。。

継承はクラスにしかできないものだと思っていました。
上記のソースなら、class Form2 : Formこれが継承を行っている部分だと考えています。

継承するつもりがなくてもForm2のオブジェクトをつくるためにインスタンスはするのでクラスの定義は必要だと思うのですが、そういうことではないのでしょうか?

補足日時:2014/04/04 18:07
    • good
    • 0

例えば1番目のリンク先である[70551]番に記されているコード。



ここでForm2クラスのコードとして以下のコードがありますね。
public event EventHandler TextBox1Changed;


これを作った後に、Form2を利用するフォームを作成してみてください。
Visual Studioのデザイナ表示時、プロパティウィンドウ上で
プロパティの設定変更やイベントの定義を行うと思います。
この『イベント』の一覧の中に、『TextBox1Changed』が存在するはずです。


つまり、継承先のクラス内で、イベントとして定義できる状態にしているわけです。



次に、if (Time != null)の部分ですが、申し訳ありませんが、私はCには明るくない為、
プロトタイプ宣言というのがよくわかりません。
が、なぜこうしているかというのは分かります。

イベントハンドラは、定義したところで、どこかでイベントを発行するように処理していないと
意味がないということはご存じに通りかと思います。
しかし、イベントというものは当然ですが、不要なら定義しません。
例えばボタンのイベントとして複数存在しますが、Clickイベントくらいしか定義
しなかったりしますよね?

その為、継承元のイベントを発行させる部分で、無条件にイベント処理を走行させようとすると、
定義していない為、エラーになります。
Time != nullが真となるタイミングは、継承先でイベントが定義されている場合です。
    • good
    • 0
この回答へのお礼

さっそくの返答ありがとうございます。

イベントハンドラは基本的に継承した後のことを意識して作る場合に必要なイメージを持ちました。
ということは、クラスを定義して定義したクラスからインスタンスはおこなえど、継承をするつもりがないのであればイベントハンドラは定義する必要のないものなのでしょうか?

お礼日時:2014/04/04 17:05

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