Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Clarification of Evenhandling? 2

Status
Not open for further replies.

daedelous

Technical User
Mar 30, 2004
8
NO
I'm not sure I grasp the finer points of event calling and handling in vb.net. This code for example:

Sub TestEvents()
Dim Obj As New Class1()
' Associate an event handler with an event.
AddHandler Obj.Ev_Event, AddressOf EventHandler
Obj.CauseSomeEvent() ' Ask the object to raise an event.
End Sub

Sub EventHandler()
' This procedure handles events raised by the object Obj.
MsgBox("EventHandler caught event.") ' Handle the event.
End Sub

Public Class Class1
Public Event Ev_Event() ' Declare an event.
Sub CauseSomeEvent()
RaiseEvent Ev_Event() ' Raise an event.
End Sub
End Class

...should demonstrate how to start and stop eventhandling in your program. But I don't see in what case one can't just substitute the code pasted here with normal function calls.

On the other hand I have this problem. I want to open this form of mine. I have already written code for this, this code is executed by the menuitem miComentary click event.
But I want to execute this same code from another button in my program..can't I force the program to raise the miCommentary_click even somehow? I tried calling it as a normal function, but I have problem figuring out what the valid parameters should be (ByVal sender As System.Object, ByVal e As System.EventArgs)

well, thanks for reading this far

Yours truly
Daed
 
Your second question first:
Try calling the routine with Whatever_Click(nothing, nothing). It's asking you for two types of objects. You need to either supply those types -- although System.Object is flexible -- or send nothing.

For the first question:
Consider one of my favorite types of programs--a baseball simulation. Let's say there is a GUI interface to look up teams and players, etc. But you can do this while simulating a game. The "Game" is its own object. When the game is over, it would be appropriate for the user to check out the box score. So you would want the "Game" object or class to raise an event, notifying the GUI class. The GUI could then prompt the user if he or she wanted to look at the box score. This beats looping inside a thread from the GUI class and querying the Game class repeatedly to see if it is over. It is also good design that the game class doesn't contain any logic to deal will showing a boxscore on the screen to the user. So, you would not want to code that into the Game class. The Game class just needs to raise an event saying its done, letting the class that instantiated it decide what to do next.
 
Thanks for the quick response Riverguy :)

Here's a quick followup...apart from the fact that i might not be good design...why not just let the Game class call( when the game is finished) a gui class function that handles the code to let the user know the game is finished? why use an event?

Thanks again

 
Because the Game class should be reusable. Let's say that the following year a new version was created. But most of the enhancements were for the user experience, not the game engine. If the Game class called the user interface, then both would have to be modified. The Game class shouldn't have to be dependant on the user interface at all.

Also keep in mind that if the Game class relied on an object reference of type UserInterface, then the game class would be bound to the UserInfterface. The disadvantage would be in the case of maybe the developers wanted to make the user interface optional. Maybe it can run as a Windows service. Raising its own event might require the windows service to do somthing else--the Windows Service might go on to the next game, whereas the User Interface might handle the event by prompting the user to take an action.
 
Thanks alot...I think I see the light now.Though it made me realize that my current ongoing VB project is about as flexible as the Rocky Mountains. Thanks for the help River
 
i definitely do not understand the finer points of event raising and handling, RiverGuy, in your baseball game example which of daedelous's

subs would be the game and the GUI?

Sub TestEvents()
Dim Obj As New Class1()
' Associate an event handler with an event.
AddHandler Obj.Ev_Event, AddressOf EventHandler
Obj.CauseSomeEvent() ' Ask the object to raise an event.
End Sub

Sub EventHandler()
' This procedure handles events raised by the object Obj.
MsgBox("EventHandler caught event.") ' Handle the event.
End Sub

Public Class Class1
Public Event Ev_Event() ' Declare an event.
Sub CauseSomeEvent()
RaiseEvent Ev_Event() ' Raise an event.
End Sub
End Class
 
mrmovie,

I really can't answer that because I don't know what its doing. Its obvious there is 2 classes, although 1 is implied.

Although now that I look at it more closely, it is declaring an object, and calling a method to raise its event.

In my example, this would be like the GUI class raising an event in the game class to tell it to maybe pause, cancel, stop simulating, maybe change a pitcher. But you could also accomplish the same thing without an event in the game class. I would probably have it call a method that makes the game cancel. After the method was complete, then I would raise the event to say it was canceled, letting the GUI class know that it can now inform the user.
 
thanks RiverGuy,

i take it your example of a baseball game would require the game to be using a different thread? if so, is this how threads communicate with each other? using events?

thanks
mrmovie
 
Read this article in the VS.Net help:

Walkthrough: Authoring a Simple Multithreaded Component with Visual Basic
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top