I always define events with two parameters

[**Developer**]

I always define events with the parameters

ByVal sender As Object, ByVal e As EventArgs

Even if they are not used.

Seems I read someplace that's the thing to do.

So I then do:

RaiseEvent AbortAll(Nothing, Nothing)

Does that make sense to you?

Is that the standard practice?





Thanks

 

[Mattias Sjögren]

RaiseEvent AbortAll(Nothing, Nothing)

Does that make sense to you?

Most event consumers will not expect either of the arguments to be
Nothing. I'd do

RaiseEvent AbortAll(Me, EventArgs.Empty)



Mattias

 

[Cor Ligthert [MVP]]

Hi,

You will be punished by Herfried,

(I do it that way again as you write)

And before I will be punished as well (what I probably will despite that).

It gives you the posibility to use inside the event

If sender Is Nothing 'Then it is from inside the program.

(what is the same as in Mattias sample,
If sender Is me. What I have used in past).



Cor

 

[Guest]

So I then do:

RaiseEvent AbortAll(Nothing, Nothing)
Does that make sense to you?
No.

Is that the standard practice?

There is an unenforced convention that says you should make a class that
inherits eventargs, you put your event info in your properties in this new
class, and when you raise the event, you supply a sender (a form, a control,
an object of yours) and an instance of your class. It is described in the
..net help. A general benefit of this approach is that a property can be
added to the class without breaking the syntax of raising and handling the
event - if a new piece of event info is added, you would have to change all
event handlers. The consequences of that re the form load event, for
instance, are too awful to contemplate.

An alternative view is that events are just like methods and the calling
sequence can be whatever the class designer wants it to be. The idea is that
public methods provide a public face to the object for functionality, and
public events provide a public face to the object for
outloading/progress/notification/whatever. I prefer this approach in my own
apps, but I prefer convention in any circumstance where the class raising the
event could be widely deployed.

 

[Herfried K. Wagner [MVP]]

You will be punished by Herfried,

That's indeed true.

 

[Jay B. Harlow [MVP - Outlook]]

**Developer**
In addition to the other comments:

I normally define my events as:

Public Event SomeNotification As EventHandler

As EventHandler is a Delegate that is defined with the sender & e
parameters. Indirectly this minimizes the number of Delegates that are
defined. If you define your event as:

Public Class Something
Public Event SomeNotification (ByVal sender As Object, ByVal e As
EventArgs)
End Class

Then VB creates a hidden Delegate for you, which you see in ILDASM.EXE as
Something.SomeNotificationEventHandler.

If you have a lot of events like SomeNotification, then you wind up with a
lot of Delegate types that are defined identically, leading to Assembly
bloat...


I normally call an OnSomeNotification sub to raise the event.

OnSomeNotification(EventArgs.Empty)

When I raise the event, where OnSomeNotification is defined as:

Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
RaiseEvent AbortAll(Me, e)
End Sub

Using OnSomeNotification allows derived classes to both raise the event & to
add code before and/or after the event is raised. Normally I simply override
OnSomeNotification to allow a derived class to simply handle the event,
rather then using AddHandler...


The above event pattern is defined at:

http://msdn.microsoft.com/library/d.../cpgenref/html/cpconeventnamingguidelines.asp
and
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp


--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


|I always define events with the parameters
|
| ByVal sender As Object, ByVal e As EventArgs
|
| Even if they are not used.
|
| Seems I read someplace that's the thing to do.
|
| So I then do:
|
| RaiseEvent AbortAll(Nothing, Nothing)
|
| Does that make sense to you?
|
| Is that the standard practice?
|
|
|
|
|
| Thanks
|
|

 

[**Developer**]

thanks

There is an unenforced convention that says you should make a class that
inherits eventargs, you put your event info in your properties in this new
class, and when you raise the event, you supply a sender (a form, a
control,
an object of yours) and an instance of your class. It is described in the
.net help. A general benefit of this approach is that a property can be
added to the class without breaking the syntax of raising and handling the
event - if a new piece of event info is added, you would have to change
all
event handlers. The consequences of that re the form load event, for
instance, are too awful to contemplate.

An alternative view is that events are just like methods and the calling
sequence can be whatever the class designer wants it to be. The idea is
that
public methods provide a public face to the object for functionality, and
public events provide a public face to the object for
outloading/progress/notification/whatever. I prefer this approach in my
own
apps, but I prefer convention in any circumstance where the class raising
the
event could be widely deployed.

 

[**Developer**]

Great

Thanks

 

[Jay B. Harlow [MVP - Outlook]]

Doh!!

That should be:
| Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| RaiseEvent SomeNotification(Me, e)
| End Sub

Obviously the OnSomeNotification raises the SomeNotification event & not the
AbortAll event as I showed. ;-)

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


message | **Developer**
| In addition to the other comments:
|
| I normally define my events as:
|
| Public Event SomeNotification As EventHandler
|
| As EventHandler is a Delegate that is defined with the sender & e
| parameters. Indirectly this minimizes the number of Delegates that are
| defined. If you define your event as:
|
| Public Class Something
| Public Event SomeNotification (ByVal sender As Object, ByVal e As
| EventArgs)
| End Class
|
| Then VB creates a hidden Delegate for you, which you see in ILDASM.EXE as
| Something.SomeNotificationEventHandler.
|
| If you have a lot of events like SomeNotification, then you wind up with a
| lot of Delegate types that are defined identically, leading to Assembly
| bloat...
|
|
| I normally call an OnSomeNotification sub to raise the event.
|
| OnSomeNotification(EventArgs.Empty)
|
| When I raise the event, where OnSomeNotification is defined as:
|
| Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| RaiseEvent AbortAll(Me, e)
| End Sub
|
| Using OnSomeNotification allows derived classes to both raise the event &
to
| add code before and/or after the event is raised. Normally I simply
override
| OnSomeNotification to allow a derived class to simply handle the event,
| rather then using AddHandler...
|
|
| The above event pattern is defined at:
|
|
http://msdn.microsoft.com/library/d.../cpgenref/html/cpconeventnamingguidelines.asp
| and
|
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp
|
|
| --
| Hope this helps
| Jay [MVP - Outlook]
| T.S. Bradley - http://www.tsbradley.net
|
|
| ||I always define events with the parameters
||
|| ByVal sender As Object, ByVal e As EventArgs
||
|| Even if they are not used.
||
|| Seems I read someplace that's the thing to do.
||
|| So I then do:
||
|| RaiseEvent AbortAll(Nothing, Nothing)
||
|| Does that make sense to you?
||
|| Is that the standard practice?
||
||
||
||
||
|| Thanks
||
||
|
|

 

[**Developer**]

I've been reading the Help Doc and am confused about the Empty field.
Which is type EventArgs.
What is that all about?

Doh!!

That should be:
| Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| RaiseEvent SomeNotification(Me, e)
| End Sub

Obviously the OnSomeNotification raises the SomeNotification event & not
the
AbortAll event as I showed. ;-)

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


message | **Developer**
| In addition to the other comments:
|
| I normally define my events as:
|
| Public Event SomeNotification As EventHandler
|
| As EventHandler is a Delegate that is defined with the sender & e
| parameters. Indirectly this minimizes the number of Delegates that are
| defined. If you define your event as:
|
| Public Class Something
| Public Event SomeNotification (ByVal sender As Object, ByVal e As
| EventArgs)
| End Class
|
| Then VB creates a hidden Delegate for you, which you see in ILDASM.EXE
as
| Something.SomeNotificationEventHandler.
|
| If you have a lot of events like SomeNotification, then you wind up with
a
| lot of Delegate types that are defined identically, leading to Assembly
| bloat...
|
|
| I normally call an OnSomeNotification sub to raise the event.
|
| OnSomeNotification(EventArgs.Empty)
|
| When I raise the event, where OnSomeNotification is defined as:
|
| Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| RaiseEvent AbortAll(Me, e)
| End Sub
|
| Using OnSomeNotification allows derived classes to both raise the event
&
to
| add code before and/or after the event is raised. Normally I simply
override
| OnSomeNotification to allow a derived class to simply handle the event,
| rather then using AddHandler...
|
|
| The above event pattern is defined at:
|
|
http://msdn.microsoft.com/library/d.../cpgenref/html/cpconeventnamingguidelines.asp
| and
|
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp
|
|
| --
| Hope this helps
| Jay [MVP - Outlook]
| T.S. Bradley - http://www.tsbradley.net
|
|
| ||I always define events with the parameters
||
|| ByVal sender As Object, ByVal e As EventArgs
||
|| Even if they are not used.
||
|| Seems I read someplace that's the thing to do.
||
|| So I then do:
||
|| RaiseEvent AbortAll(Nothing, Nothing)
||
|| Does that make sense to you?
||
|| Is that the standard practice?
||
||
||
||
||
|| Thanks
||
||
|
|

 

[Mattias Sjögren]

I've been reading the Help Doc and am confused about the Empty field.
Which is type EventArgs.
What is that all about?

It's like a dummy EventArgs instance you can supply when you don't
have anything else to add. By reusing the same instance you can save a
lot of small object allocations.


Mattias

 

[Jay B. Harlow [MVP - Outlook]]

**Developer**,
As Mattias suggests, its used to prevent a lot of allocations of EventArgs
objects, which have no mutable attributes. Preventing the allocations should
help performance, as the GC won't need to work as much...

Creating a shared readonly property or field called "Empty" is a common
pattern used in the framework for Immutable types. For example:

- String.Empty
- EventArgs.Empty
- Match.Empty
- Color.Empty

Its used whenever there is an "default instance" that can/should be used
instead of allocating a new instance of the class. In the case of a
structure, its useful to have an uninitialized ("Empty") value of the
structure.

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


| I've been reading the Help Doc and am confused about the Empty field.
| Which is type EventArgs.
| What is that all about?
|
|
|
|
|
| message | > Doh!!
| >
| > That should be:
| > | Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| > | RaiseEvent SomeNotification(Me, e)
| > | End Sub
| >
| > Obviously the OnSomeNotification raises the SomeNotification event & not
| > the
| > AbortAll event as I showed. ;-)
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > message | > | **Developer**
| > | In addition to the other comments:
| > |
| > | I normally define my events as:
| > |
| > | Public Event SomeNotification As EventHandler
| > |
| > | As EventHandler is a Delegate that is defined with the sender & e
| > | parameters. Indirectly this minimizes the number of Delegates that are
| > | defined. If you define your event as:
| > |
| > | Public Class Something
| > | Public Event SomeNotification (ByVal sender As Object, ByVal e
As
| > | EventArgs)
| > | End Class
| > |
| > | Then VB creates a hidden Delegate for you, which you see in ILDASM.EXE
| > as
| > | Something.SomeNotificationEventHandler.
| > |
| > | If you have a lot of events like SomeNotification, then you wind up
with
| > a
| > | lot of Delegate types that are defined identically, leading to
Assembly
| > | bloat...
| > |
| > |
| > | I normally call an OnSomeNotification sub to raise the event.
| > |
| > | OnSomeNotification(EventArgs.Empty)
| > |
| > | When I raise the event, where OnSomeNotification is defined as:
| > |
| > | Protected Overridable Sub OnSomeNotification(ByVal e As EventArgs)
| > | RaiseEvent AbortAll(Me, e)
| > | End Sub
| > |
| > | Using OnSomeNotification allows derived classes to both raise the
event
| > &
| > to
| > | add code before and/or after the event is raised. Normally I simply
| > override
| > | OnSomeNotification to allow a derived class to simply handle the
event,
| > | rather then using AddHandler...
| > |
| > |
| > | The above event pattern is defined at:
| > |
| > |
| >
http://msdn.microsoft.com/library/d.../cpgenref/html/cpconeventnamingguidelines.asp
| > | and
| > |
| >
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp
| > |
| > |
| > | --
| > | Hope this helps
| > | Jay [MVP - Outlook]
| > | T.S. Bradley - http://www.tsbradley.net
| > |
| > |
| > | | > ||I always define events with the parameters
| > ||
| > || ByVal sender As Object, ByVal e As EventArgs
| > ||
| > || Even if they are not used.
| > ||
| > || Seems I read someplace that's the thing to do.
| > ||
| > || So I then do:
| > ||
| > || RaiseEvent AbortAll(Nothing, Nothing)
| > ||
| > || Does that make sense to you?
| > ||
| > || Is that the standard practice?
| > ||
| > ||
| > ||
| > ||
| > ||
| > || Thanks
| > ||
| > ||
| > |
| > |
| >
| >
|
|

 

[**Developer**]

I feel like I'm taking advantage of your helpfulness but I haven't quite got
a hold of this.

If I were developing a class might I check for an argument value of Empty
and react accordingly?

Seems to me what is recommended is to define the event as (ByVal sender As
Object, ByVal e As EventArgs)

Then raise it with (Me,EventArgs.Empty)

When it could have been defined as (ByVal sender As Object)
and raised with (Me) which is simpler and cleaner.

Is that true?


Thanks a lot


PS
Bottom line: If I define an Event that requires no data when raised
I should use (ByVal sender As Object, ByVal e As EventArgs)

and raise it with (Me,EventArgs.Empty)

**Developer**,
As Mattias suggests, its used to prevent a lot of allocations of EventArgs
objects, which have no mutable attributes. Preventing the allocations
should
help performance, as the GC won't need to work as much...

Creating a shared readonly property or field called "Empty" is a common
pattern used in the framework for Immutable types. For example:

- String.Empty
- EventArgs.Empty
- Match.Empty
- Color.Empty

Its used whenever there is an "default instance" that can/should be used
instead of allocating a new instance of the class. In the case of a
structure, its useful to have an uninitialized ("Empty") value of the
structure.

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


| I've been reading the Help Doc and am confused about the Empty field.
| Which is type EventArgs.
| What is that all about?
|
|
|
|
|
| message | > Doh!!
| >
| > That should be:
| > | Protected Overridable Sub OnSomeNotification(ByVal e As
EventArgs)
| > | RaiseEvent SomeNotification(Me, e)
| > | End Sub
| >
| > Obviously the OnSomeNotification raises the SomeNotification event &
not
| > the
| > AbortAll event as I showed. ;-)
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
in
| > message | > | **Developer**
| > | In addition to the other comments:
| > |
| > | I normally define my events as:
| > |
| > | Public Event SomeNotification As EventHandler
| > |
| > | As EventHandler is a Delegate that is defined with the sender & e
| > | parameters. Indirectly this minimizes the number of Delegates that
are
| > | defined. If you define your event as:
| > |
| > | Public Class Something
| > | Public Event SomeNotification (ByVal sender As Object, ByVal
e
As
| > | EventArgs)
| > | End Class
| > |
| > | Then VB creates a hidden Delegate for you, which you see in
ILDASM.EXE
| > as
| > | Something.SomeNotificationEventHandler.
| > |
| > | If you have a lot of events like SomeNotification, then you wind up
with
| > a
| > | lot of Delegate types that are defined identically, leading to
Assembly
| > | bloat...
| > |
| > |
| > | I normally call an OnSomeNotification sub to raise the event.
| > |
| > | OnSomeNotification(EventArgs.Empty)
| > |
| > | When I raise the event, where OnSomeNotification is defined as:
| > |
| > | Protected Overridable Sub OnSomeNotification(ByVal e As
EventArgs)
| > | RaiseEvent AbortAll(Me, e)
| > | End Sub
| > |
| > | Using OnSomeNotification allows derived classes to both raise the
event
| > &
| > to
| > | add code before and/or after the event is raised. Normally I simply
| > override
| > | OnSomeNotification to allow a derived class to simply handle the
event,
| > | rather then using AddHandler...
| > |
| > |
| > | The above event pattern is defined at:
| > |
| > |
| >
http://msdn.microsoft.com/library/d.../cpgenref/html/cpconeventnamingguidelines.asp
| > | and
| > |
| >
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp
| > |
| > |
| > | --
| > | Hope this helps
| > | Jay [MVP - Outlook]
| > | T.S. Bradley - http://www.tsbradley.net
| > |
| > |
| > | | > ||I always define events with the parameters
| > ||
| > || ByVal sender As Object, ByVal e As EventArgs
| > ||
| > || Even if they are not used.
| > ||
| > || Seems I read someplace that's the thing to do.
| > ||
| > || So I then do:
| > ||
| > || RaiseEvent AbortAll(Nothing, Nothing)
| > ||
| > || Does that make sense to you?
| > ||
| > || Is that the standard practice?
| > ||
| > ||
| > ||
| > ||
| > ||
| > || Thanks
| > ||
| > ||
| > |
| > |
| >
| >
|
|

 

[**Developer**]

I didn't know how to handle this. I want to reply to you the same as I did
to Jay so I just cut-pasted the same text rather than suggesting you read
the reply to him. All I'm saying is that if you read the reply to him and it
looks identical to this - that's because it is identical.

If I were developing a class might I check for an argument value of Empty
and react accordingly?

Seems to me what is recommended is to define the event as (ByVal sender As
Object, ByVal e As EventArgs)

Then raise it with (Me,EventArgs.Empty)

When it could have been defined as (ByVal sender As Object)
and raised with (Me) which is simpler and cleaner.

Is that true?


Thanks a lot


PS
Bottom line: If I define an Event that requires no data when raised
I should use (ByVal sender As Object, ByVal e As EventArgs)

and raise it with (Me,EventArgs.Empty)

 

[Jay B. Harlow [MVP - Outlook]]

**Developer**
| When it could have been defined as (ByVal sender As Object)
| and raised with (Me) which is simpler and cleaner.
It could have been defined that way. (It Could have).

However it wasn't! The .NET Developer's guidelines state that all events
have 2 parameters. Rather then have some with 2 parameters, some with 1
parameters. Or worse: there is no real convention, where some have 0, some
have 1, some have 2, some have 3, ..., some have 16...

It may appear to be simpler & cleaner, however consider that (in theory) any
event handler with Object & EventArgs parameters should be able to handle
any event. If all events have 2 parameters then this is achievable, if some
have 1 & some have 2 then it is not.

I understand .NET 2.0's Contravariant Delegates we will actually be able to
do this.

http://msdn2.microsoft.com/en-us/library/ms173174#

I have not yet tried contravariant delegates in VB 2005. I'll report back if
they don't work in beta 2.

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


|I feel like I'm taking advantage of your helpfulness but I haven't quite
got
| a hold of this.
|
| If I were developing a class might I check for an argument value of Empty
| and react accordingly?
|
| Seems to me what is recommended is to define the event as (ByVal sender As
| Object, ByVal e As EventArgs)
|
| Then raise it with (Me,EventArgs.Empty)
|
| When it could have been defined as (ByVal sender As Object)
| and raised with (Me) which is simpler and cleaner.
|
| Is that true?
|
|
| Thanks a lot
|
|
| PS
| Bottom line: If I define an Event that requires no data when raised
| I should use (ByVal sender As Object, ByVal e As EventArgs)
|
| and raise it with (Me,EventArgs.Empty)
|
|
|
<<snip>>

 

[**Developer**]

**Developer**
| When it could have been defined as (ByVal sender As Object)
| and raised with (Me) which is simpler and cleaner.
It could have been defined that way. (It Could have).

However it wasn't!

I meant to refer to an event that I defined so I could do it any way I
wanted to.

The consumer would have to know if it was
(ByVal sender As Object, ByVal e As MouseEventArgs)

or

(ByVal sender As Object, ByVal e As EventArgs)

so I don't se why it would be a problem for him to know it was

(By sender As Object)

in any event I now understand and will comply.

Thanks for the help.



PS

Why does your site and company use a name that is not your name.

I was confused when I first got there - thinking I was in the wrong place.

 

[Jay B. Harlow [MVP - Outlook]]

**developer**
| I meant to refer to an event that I defined so I could do it any way I
| wanted to.
Obviously the Guidelines are just that, Guidelines. You can choose to follow
them or not.

I try to follow them so my code is consistent with other .NET developers
code...

| Why does your site and company use a name that is not your name.
Bradley is my middle name, T.S. is from The World According to Garp, T.S.
could stand for Technical Services. I like the way T.S. Bradley sounds so I
use it. When I offer some of the products I am working on T.S. Bradley makes
more sense then Jay B. Harlow.


--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net


|
| message | > **Developer**
| > | When it could have been defined as (ByVal sender As Object)
| > | and raised with (Me) which is simpler and cleaner.
| > It could have been defined that way. (It Could have).
| >
| > However it wasn't!
|
| I meant to refer to an event that I defined so I could do it any way I
| wanted to.
|
| The consumer would have to know if it was
| (ByVal sender As Object, ByVal e As MouseEventArgs)
|
| or
|
| (ByVal sender As Object, ByVal e As EventArgs)
|
| so I don't se why it would be a problem for him to know it was
|
| (By sender As Object)
|
| in any event I now understand and will comply.
|
| Thanks for the help.
|
|
|
| PS
|
| Why does your site and company use a name that is not your name.
|
| I was confused when I first got there - thinking I was in the wrong place.
|
|
|
|
|
|
|
|

 

[Cor Ligthert [MVP]]

Jay,

I am not a guy from the US, so English sound probably different in my ears
than to Americans. Know with that, that almost every real better good
educatial book is in English here and most of us switch talking and thinking
in "English" without even notice it (Writing is something else)



I don't know if it interest you, however Jay B. Harlow, sounds really good
in my ears, it has something distinct, while T.S Bradley sounds really flat.



Cor

 

[**Developer**]

Hope this helps
As always, it does

Thanks