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(Nothin g, Nothing)

Does that make sense to you?

Is that the standard practice?

Thanks

[Mattias Sjögren]

>RaiseEvent AbortAll(Nothin g, 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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[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

[AMercer]

> So I then do:

RaiseEvent AbortAll(Nothin g, 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]]

"Cor Ligthert [MVP]" <no************ @planet.nl> schrieb:

You will be punished by Herfried,

That's indeed true.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Jay B. Harlow [MVP - Outlook]]

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

I normally define my events as:

Public Event SomeNotificatio n 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 SomeNotificatio n (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.SomeN otificationEven tHandler.

If you have a lot of events like SomeNotificatio n, then you wind up with a
lot of Delegate types that are defined identically, leading to Assembly
bloat...
I normally call an OnSomeNotificat ion sub to raise the event.

OnSomeNotificat ion(EventArgs.E mpty)

When I raise the event, where OnSomeNotificat ion is defined as:

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

Using OnSomeNotificat ion allows derived classes to both raise the event & to
add code before and/or after the event is raised. Normally I simply override
OnSomeNotificat ion 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/de...guidelines.asp
and
http://msdn.microsoft.com/library/de...Guidelines.asp
--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net
" **Developer**" <RE************ *@a-znet.com> wrote in message
news:e%******** ********@TK2MSF TNGP12.phx.gbl. ..
|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(Nothin g, Nothing)
|
| Does that make sense to you?
|
| Is that the standard practice?
|
|
|
|
|
| Thanks
|
|

[**Developer**]

thanks

"AMercer" <AM*****@discus sions.microsoft .com> wrote in message
news:B5******** *************** ***********@mic rosoft.com...

So I then do:
RaiseEvent AbortAll(Nothin g, 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.

[**Developer**]

Great

Thanks
"Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
message news:ex******** ******@TK2MSFTN GP12.phx.gbl...

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

I normally define my events as:

Public Event SomeNotificatio n 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 SomeNotificatio n (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.SomeN otificationEven tHandler.

If you have a lot of events like SomeNotificatio n, then you wind up with a
lot of Delegate types that are defined identically, leading to Assembly
bloat...
I normally call an OnSomeNotificat ion sub to raise the event.

OnSomeNotificat ion(EventArgs.E mpty)

When I raise the event, where OnSomeNotificat ion is defined as:

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

Using OnSomeNotificat ion allows derived classes to both raise the event &
to
add code before and/or after the event is raised. Normally I simply
override
OnSomeNotificat ion 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/de...guidelines.asp
and
http://msdn.microsoft.com/library/de...Guidelines.asp
--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net
" **Developer**" <RE************ *@a-znet.com> wrote in message
news:e%******** ********@TK2MSF TNGP12.phx.gbl. ..
|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(Nothin g, Nothing)
|
| Does that make sense to you?
|
| Is that the standard practice?
|
|
|
|
|
| Thanks
|
|

[Jay B. Harlow [MVP - Outlook]]

Doh!!

That should be:
| Protected Overridable Sub OnSomeNotificat ion(ByVal e As EventArgs)
| RaiseEvent SomeNotificatio n(Me, e)
| End Sub

Obviously the OnSomeNotificat ion raises the SomeNotificatio n event & not the
AbortAll event as I showed. ;-)

--
Hope this helps
Jay [MVP - Outlook]
T.S. Bradley - http://www.tsbradley.net
"Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
message news:ex******** ******@TK2MSFTN GP12.phx.gbl...
| **Developer**
| In addition to the other comments:
|
| I normally define my events as:
|
| Public Event SomeNotificatio n 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 SomeNotificatio n (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.SomeN otificationEven tHandler.
|
| If you have a lot of events like SomeNotificatio n, then you wind up with a
| lot of Delegate types that are defined identically, leading to Assembly
| bloat...
|
|
| I normally call an OnSomeNotificat ion sub to raise the event.
|
| OnSomeNotificat ion(EventArgs.E mpty)
|
| When I raise the event, where OnSomeNotificat ion is defined as:
|
| Protected Overridable Sub OnSomeNotificat ion(ByVal e As EventArgs)
| RaiseEvent AbortAll(Me, e)
| End Sub
|
| Using OnSomeNotificat ion allows derived classes to both raise the event &
to
| add code before and/or after the event is raised. Normally I simply
override
| OnSomeNotificat ion 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/de...guidelines.asp
| and
|
http://msdn.microsoft.com/library/de...Guidelines.asp
|
|
| --
| Hope this helps
| Jay [MVP - Outlook]
| T.S. Bradley - http://www.tsbradley.net
|
|
| " **Developer**" <RE************ *@a-znet.com> wrote in message
| news:e%******** ********@TK2MSF TNGP12.phx.gbl. ..
||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(Nothin g, 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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.