Is the usual Event format the only way to go?

[active]

Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

....

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)



Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?



Thanks

 

[Guest]

active,

A convention is only useful if it is followed.

The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.

Of course, nothing is preventing you from using any event signature that
works for you.

Kerry Moorman

 

[active]

thanks for your comments

active,

A convention is only useful if it is followed.

The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.

Of course, nothing is preventing you from using any event signature that
works for you.

Kerry Moorman

 

[Phill W.]

Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be.

And therein lies the crux of the argument.

How can code that you write /today/ know who or what might be throwing
this event at it at any point in the Future?

Events are most commonly raised by Controls so that other code
(Handlers) can react to it, usually making some change to the sending
Control as well. For example, if you click on a Button, you probably
want the Click handler to disable the button until it's ready to do its
job again. Without a reference to the sender, you can't do that - you
wouldn't know who had sent you the event.

Of course, you may not actually need all this - if the Handler is simple
enough that you don't need to ask the sender anything or do anything to
it, then fine; your second, shorter syntax will do the job nicely ...
until you add that /little/ bit of code into the Handler that /does/
need to go back to the sender ... and you have to start recompiling
everything all over the place to add the sender argument back in... ;-)

HTH,
Phill W.

 

[Chris Dunaway]

Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks

In addition to the other posts, what I put a number of instances in an
array and one of them raises the event. How will I know which one of
them did it?

Chris

 

[active]

Regarding the possible future need for knowing the sender, it's just as
likely if I 'add a little bit of code' that the class I generate
(HeightChangeEventArgs) may be insufficient and will need to be changed.

Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove

Don't I know the sender

I'm not considering not sending the sender in situations when the sender is
not apparent.

I have a few situations where a usercontol needs to advise the form that the
file path has been changed so the form can update its caption. Creating a
class to do this only complicates a simple procedure.

Would you say almost everyone follows the convention?

Guess that is my basic question.



Thanks

 

[active]

I would include the sender in that case.

thanks

 

[Chris Dunaway]

Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove

Don't I know the sender

What if you had:

Handles Splitter1.MouseMove, Splitter2.MouseMove

In the MouseMove event you want to know which splitter fired the
event.

Chris

 

[active]

I'd include sender

I work alone and was basically wondering if most programmers follow the
convention in those cases when it is not necessary to do so. Do you think
they do.

thanks

 

[rowe_newsgroups]

I'd include sender

I think what Chris is saying is what if you have

Handles Splitter1.MouseMove

And you don't add a sender because you have no need. At a later time
you decide to have it handle another another

Handles Splittle1.MouseMove, Splitter2.MouseMove

Now you must rewrite the event to account for the sender, and if you
based all the code in the event handler on Splitter1 you know must
rewrite that code to account for Splitter2. The point is, why not just
include sender in the first place and make the code more flexible from
the beginning? In my experience, no matter how much planning you do,
the original program will morph at some point during development. This
is why I try to use the most flexible coding patterns I can - a little
time now often save a lot of time later.

In summary, do what you want - If your team (which in your case is
just you) all agrees on a design pattern, then you shouldn't be afraid
to use it.

Thanks,

Seth Rowe

 

[active]

We're focusing on Sender, and I do see the point, but it is the other
argument that I'm most interested in.

I think I was wondering if everyone else is following the convention (as I
have so far).

I put together a little example of the two ways I might go about it.

I like the second because it is simpler and less error prone, that's all.

I think anything that complicates code should be at least thought about.

Thanks for all the replies


Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal e As XChangedEventArgs)

Public NotInheritable Class XChangedEventArgs
Inherits EventArgs
Private mX As Integer

Public Sub New(ByVal value As Integer)
MyBase.New()
mX = value
End Sub

Public ReadOnly Property X() As Integer
Get
X = mX
End Get
End Property
End Class

Private Sub zz()
RaiseEvent XChanged(New XChangedEventArgs(400))
End Sub
End Class
'---
Private Sub UC1_XChanged( ByVal e As UCN.UC.XChangedEventArgs) Handles
UC1.XChanged
'... use.. e.X)
End Sub

----

or

----
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal X As Integer)

Private Sub zz()
RaiseEvent XChanged(400)
End Sub
End Class
'---
Private Sub UC1_XChanged(ByVal x As Integer) Handles UC1.XChanged
'...use.. X
End Sub

 

[Lloyd Sheen]

We're focusing on Sender, and I do see the point, but it is the other
argument that I'm most interested in.

I think I was wondering if everyone else is following the convention (as I
have so far).

I put together a little example of the two ways I might go about it.

I like the second because it is simpler and less error prone, that's all.

I think anything that complicates code should be at least thought about.

Thanks for all the replies


Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal e As XChangedEventArgs)

Public NotInheritable Class XChangedEventArgs
Inherits EventArgs
Private mX As Integer

Public Sub New(ByVal value As Integer)
MyBase.New()
mX = value
End Sub

Public ReadOnly Property X() As Integer
Get
X = mX
End Get
End Property
End Class

Private Sub zz()
RaiseEvent XChanged(New XChangedEventArgs(400))
End Sub
End Class
'---
Private Sub UC1_XChanged( ByVal e As UCN.UC.XChangedEventArgs) Handles
UC1.XChanged
'... use.. e.X)
End Sub

----

or

----
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal X As Integer)

Private Sub zz()
RaiseEvent XChanged(400)
End Sub
End Class
'---
Private Sub UC1_XChanged(ByVal x As Integer) Handles UC1.XChanged
'...use.. X
End Sub

I think your last comment is true (it should be thought about). That is the
point of the Dot.Net framework and the "standards" for using it. The
argument that while it looks simple now but just watch is so very true. As
soon as you have completed your work a requirement will come up (lets say
the UserControl is so handy that it will now be used all over the place) and
then you will be "forced" to go back to the standard method. Remember that
sending the two arguments, first the sender to indicate who's calling (and
that could be vital for debugging), and the an object containing the
information that is sent by the call is a better design since it can be
expanded upon. Look at all the objects which are derived from the standard
EventArgs and I think that is a good enough argument.

Lastly if you follow Dot.Net standards then maintenance will be so much
easier.

Just my thoughts,

Lloyd Sheen

 

[active]

So far it's been 5 to 0

Guess I get the point

Thanks

 

[Jay B. Harlow [MVP - Outlook]]

active,
In addition to the other comments:

I follow the convention religiously; This ensures that my predecessors will
understand my code (as it follows the convention set forth in the framework)
also it allows VB to create smaller assemblies with fewer types. Fewer types
mean the assembly will load quicker & have a smaller memory usage...
(smaller memory usage as there are fewer types loaded).

To gain a smaller assembly I define the events based on an EventHandler:

Rather then:

Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

In .Net 1.x I use:

Public Event HeightChanged As HeightChangedEventHandler

Where HeightChangedEventHandler is defined as:

Public Delegate Sub HeightChangedEventHandler(ByVal sender As Object,
ByVal e As
HeightChangeEventArgs)

In .NET 2.0 I use:

Public Event HeightChanged As EventHandler(Of HeightChangeEventArgs)

Using the "As EventHandler..." creates smaller assemblies as your syntax
causes the VB compiler to create a hidden EventHandler type for each event
you define. Using "As EventHandler..." causes VB to use either
System.EventHandler or System.EventHandler(Of T) types.

If you use Object Browser to look at the various *EventArgs types in the
Framework you will notice an accompanying *EventHandler delegate that goes
with it.

As part of Orcas (the next version of VS.NET currently in beta 1) we gain
Relaxed Delegates:

http://blogs.msdn.com/vbteam/archive/2007/04/19/visual-basic-orcas-beta1-is-in-the-wild.aspx

Which among other things allow you to define your handler without any
parameters, while the event itself includes parameters. Relaxed Delegates
also allow

 

[active]

I look forward to your tutorial-like comments since they instill an
understanding of the subject.

Thanks

active,
In addition to the other comments:

I follow the convention religiously; This ensures that my predecessors
will understand my code (as it follows the convention set forth in the
framework) also it allows VB to create smaller assemblies with fewer
types. Fewer types mean the assembly will load quicker & have a smaller
memory usage... (smaller memory usage as there are fewer types loaded).

To gain a smaller assembly I define the events based on an EventHandler:

Rather then:

Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

In .Net 1.x I use:

Public Event HeightChanged As HeightChangedEventHandler

Where HeightChangedEventHandler is defined as:

Public Delegate Sub HeightChangedEventHandler(ByVal sender As Object,
ByVal e As
HeightChangeEventArgs)

In .NET 2.0 I use:

Public Event HeightChanged As EventHandler(Of HeightChangeEventArgs)

Using the "As EventHandler..." creates smaller assemblies as your syntax
causes the VB compiler to create a hidden EventHandler type for each event
you define. Using "As EventHandler..." causes VB to use either
System.EventHandler or System.EventHandler(Of T) types.

If you use Object Browser to look at the various *EventArgs types in the
Framework you will notice an accompanying *EventHandler delegate that goes
with it.

As part of Orcas (the next version of VS.NET currently in beta 1) we gain
Relaxed Delegates:

http://blogs.msdn.com/vbteam/archive/2007/04/19/visual-basic-orcas-beta1-is-in-the-wild.aspx

Which among other things allow you to define your handler without any
parameters, while the event itself includes parameters. Relaxed Delegates
also allow

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net

Because of a strong recommendation I saw in this NG all my events are of
the form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look
into it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)



Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?



Thanks