RaiseEventのメリット

＞RaiseEventを使用しないといけない処理とは、どういうもの？
　#1さんはどう思うかわかりませんが、私は、Event化しなければならない処理というものは、とりあえずないと思っています。あなたの疑問は、#1さんの、

＞RaiseEvent myTest

の部分は、Call GlobalModule.myTest()などで実装できるはずだ、という事だと思います。ここでGlobalModule.myTest()は、GlobalModuleというModule（Bas）の中にある、myTestというSubroutineです。
　その通りです。その通りですが、GlobalModule.myTest()は、Global変数（Applicationレベルの変数）を使うようなものです。構造化プログラミングが全盛の頃、「ちゃんと管理された」Global変数の便利さを強調しすぎて、批難ごうごうになった記憶があります。
　でもGlobal機構は便利なんですよね。昔はGlobal機構の「ちゃんとした管理」は、全て自前で行う必要がありました。「自前」であるだけに、それはErrorではなく「Bug」の温床だったのです。
　状況を複雑にしているのは、VBではGlobalスコープを、そのままでは使用できない事です。それでModuleなどを用意し、そこにPublicな変数や関数を用意して、あたかもGlobalなように扱います。じっさい先のGlobalModule.myTest()は、myTest()で動くはずです。でもこれは利点なんですよ。「呼び出し先を指定しなくても良い」からです。逆に言うと、それが「Bug」の温床になる原因です。
　Eventは、ApplicationのGlobal動作の管理機構です。

　　(1)RaiseEvent myTestは、呼び出し先を指定していないので、Global機構の便利さを、そのまま使えます。
　　(2)管理は、Public Event myTest()とDim WithEvents oClass as myClassで行います。
　　(3)EventとWithEventsの対で、どのGlobal関数が、どこへ接続されるかを管理します。

　言葉で言うとわかりにくいのですが、必要に応じて（全てをEvent化せよとは、決して言いません）Eventを導入すると、(1)〜(3)の効果として、コードに非常にメリハリが付きます。これは小さい事に見えるかも知れませんが、実際上はとても重要な事です。やってみると、わかります。そして(1)〜(3)の応用が、Interface（Implements）とDelegateです。
　Event Doriven（Eventを使える事）とObject志向は、本来別物ですが、両者は非常に相性の良いものであり、どちらも「プログラマーに楽させる」ために開発されてきた技術です。なので私は、必要に応じてEventは、どんどん使うべきだと思っています。

投稿日時 - 2008-01-06 13:40:42

コントロールやクラスなどで ユーザー定義のイベントを呼び出す必要がある場合です

フォームに貼り付けたボタンなどのClickイベントなどはユーザーが独自にコードを記述できないと面白くありませんよね
この場合にコントロール側で RaiseEventをつかってユーザーが作成したClickイベントが呼ばれるようにします

一例です
クラスモジュール myClassに
Public Event myTest()
Public myTask(VyBal nValue as integer)
　　dim n as integer
　　for n = 1 to 1000
　　　　if n mod navle = 0 then
　　　　　　' ここでユーザー定義のイベントへ処理を移す
　　　　　　RaiseEvent myTest
　　　　end if
　　next
End Sub
といったコードがあったとします
これを呼び出すフォーム側では
Dim WithEvents oClass as myClass
Sub Command1_Click()
oClass.myTask(100)
End Sub

Sub Form_load()
　　Set oClass = new myClass
End Sub

Sub oClass_mTest()
　　MsgBox "myClassから呼ばれました"
End Sub
といったような使い方になります

投稿日時 - 2008-01-06 00:30:29