Question ByVal e As System.EventArgs?

[milo896]

Hello everyone. I am just learning VB.NET, and I have a question. I'm having trouble understanding what exactly ByVal e As System.EventArgs means, and how I would use it. Google helped me learn about sender, but it doesn't seem able to shed any light on e.

Here is my problem. I want to call a subroutine from another sub, but I don't know what to specify for e. I have a sub that runs when the user changes the value in a combo box. I need to call this sub again later from another sub. I know how to pass along the sender properly, but I just don't know what to do with e.

Thanks in advance.

 

[JuggaloBrotha]

e is the event arguments. The easiest way to find out what e is, is to look at the event that you're wanting to run from the other sub. In this case e is: System.EventArgs

 

[JohnH]

Calling event handlers explicitly is a bad practice, they should only be used for handling actual events that occur. Instead you can put you code in a sub method that you call from both the event handler and other places in code.

 

[cjard]

for example:

Public Sub SaveButton_Click(sender as Object, e as EventArgs) Handles SaveButton.Click

  SaveFile()

End Sub


Private Sub SaveFile()

  'save the file

End Sub

What john is saying is: never ever call in your code:

Public Sub AutoSaveTimer_Tick() Handles AutoSaveTimer.Tick

 'NEVER!
 SaveButton_Click(Nothing, Nothing)

 'ALWAYS!
 SaveFile()

EndSub

 

[milo896]

Thanks for the replies. I understand what you guys are saying. My program isn't very complex, so it won't be hard to restructure it to match what you're saying.

Now I'm wondering why it's bad practice to call the event handler directly. What kinds problems can it lead to?

 

[JohnH]

Because the purpose of those handler methods is to simply handle the event that occured. When writing that code you shouldn't need to worry about what might happen if someone called it directly from different places in code without that event really happening, that would break the purpose of the code. Problems may also occur when someone externally "fake" the event parameters, sending wrong event data that is not what the class designer intended and not what you expected when first writing the handler code. It is not good OOP programming, not a natural flow of events so to speak, and OOP is mostly about putting things where they belong.

When you write code for events you also design the execution flow. It is perfectly valid to have multiple listeners and handlers for a single event. Event handling is about what should happen if something else happens - so what happens if you break into middle of that chain? Chaos begins.

Button controls do have a special method called PerformClick that will raise the Click event thus be handled by any listeners of that event, but this is an exception, I have not seen any similar methods through out the .Net Framework. But you should be able to see how big the difference is between calling this method that causes the event to be raised and calling one of the event handler methods directly.