473,503 Members | 1,769 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

I always define events with two parameters

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
Nov 21 '05 #1
18 1429
>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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 21 '05 #2
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
Nov 21 '05 #3
> 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.

Nov 21 '05 #4
"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/>
Nov 21 '05 #5
**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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
|
| Does that make sense to you?
|
| Is that the standard practice?
|
|
|
|
|
| Thanks
|
|
Nov 21 '05 #6
thanks

"AMercer" <AM*****@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...
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.

Nov 21 '05 #7
Great

Thanks
"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:ex**************@TK2MSFTNGP12.phx.gbl...
**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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
|
| Does that make sense to you?
|
| Is that the standard practice?
|
|
|
|
|
| Thanks
|
|

Nov 21 '05 #8
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
"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:ex**************@TK2MSFTNGP12.phx.gbl...
| **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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
||
|| Does that make sense to you?
||
|| Is that the standard practice?
||
||
||
||
||
|| Thanks
||
||
|
|
Nov 21 '05 #9
I've been reading the Help Doc and am confused about the Empty field.
Which is type EventArgs.
What is that all about?

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:uI**************@TK2MSFTNGP14.phx.gbl...
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
"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:ex**************@TK2MSFTNGP12.phx.gbl...
| **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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
||
|| Does that make sense to you?
||
|| Is that the standard practice?
||
||
||
||
||
|| Thanks
||
||
|
|

Nov 21 '05 #10
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.
Nov 21 '05 #11
**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
" **Developer**" <RE*************@a-znet.com> wrote in message
news:uV**************@TK2MSFTNGP15.phx.gbl...
| I've been reading the Help Doc and am confused about the Empty field.
| Which is type EventArgs.
| What is that all about?
|
|
|
|
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
| message news:uI**************@TK2MSFTNGP14.phx.gbl...
| > 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
| >
| >
| > "Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
| > message news:ex**************@TK2MSFTNGP12.phx.gbl...
| > | **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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
| > ||
| > || Does that make sense to you?
| > ||
| > || Is that the standard practice?
| > ||
| > ||
| > ||
| > ||
| > ||
| > || Thanks
| > ||
| > ||
| > |
| > |
| >
| >
|
|
Nov 21 '05 #12
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)


"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:O1**************@TK2MSFTNGP09.phx.gbl...
**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
" **Developer**" <RE*************@a-znet.com> wrote in message
news:uV**************@TK2MSFTNGP15.phx.gbl...
| I've been reading the Help Doc and am confused about the Empty field.
| Which is type EventArgs.
| What is that all about?
|
|
|
|
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
| message news:uI**************@TK2MSFTNGP14.phx.gbl...
| > 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
| >
| >
| > "Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote
in
| > message news:ex**************@TK2MSFTNGP12.phx.gbl...
| > | **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/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%****************@TK2MSFTNGP12.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(Nothing, Nothing)
| > ||
| > || Does that make sense to you?
| > ||
| > || Is that the standard practice?
| > ||
| > ||
| > ||
| > ||
| > ||
| > || Thanks
| > ||
| > ||
| > |
| > |
| >
| >
|
|

Nov 21 '05 #13
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)

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:eH**************@TK2MSFTNGP09.phx.gbl...
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.

Nov 21 '05 #14
**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
" **Developer**" <RE*************@a-znet.com> wrote in message
news:u9*************@TK2MSFTNGP09.phx.gbl...
|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>>
Nov 21 '05 #15

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:eX**************@TK2MSFTNGP14.phx.gbl...
**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.


Nov 21 '05 #16
**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
" **Developer**" <RE*************@a-znet.com> wrote in message
news:%2*****************@TK2MSFTNGP15.phx.gbl...
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
| message news:eX**************@TK2MSFTNGP14.phx.gbl...
| > **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.
|
|
|
|
|
|
|
|
Nov 21 '05 #17
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

Nov 21 '05 #18
> Hope this helps
As always, it does

Thanks
Nov 21 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

83
15510
by: rahul8143 | last post by:
hello, what is difference between sizeof("abcd") and strlen("abcd")? why both functions gives different output when applied to same string "abcd". I tried following example for that. #include...
4
1270
by: news.microsoft.com | last post by:
In one of my books called "Mastering C#" there is a statement that reads "All event handler delegates must return void and accept two parameters. The first parameter is an object, and it represents...
1
2827
by: Natalia DeBow | last post by:
Hi, I am working on a Windows-based client-server application. I am involved in the development of the remote client modules. I am using asynchronous delegates to obtain information from...
3
1577
by: Michael Tissington | last post by:
I'm confused by documentation and examples on using Delegate to create Events for use with COM In some situation I see a parameter list of (sender as Object, e as EventArgs) and other times I...
19
5140
by: youpak2000 | last post by:
Are MAGIC numbers always bad? Using magic numbers (constant numbers) in programs are generally considered a bad programming practice, and it's recommended that to define constants in single,...
16
2871
by: anonymous.user0 | last post by:
The way I understand it, if I have an object Listener that has registered as a listener for some event Event that's produced by an object Emitter, as long as Emitter is still allocated Listener...
11
3219
by: MikeT | last post by:
This may sound very elementary, but can you trap when your object is set to null within the object? I have created a class that registers an event from an object passed in the constructor. When...
7
3406
by: Siegfried Heintze | last post by:
I'm studying the book "Microsoft Visual Basic.NET Language Reference" and I would like some clarify the difference between events and delegates. On page 156 I see a WinForms example of timer that...
1
1070
by: shapper | last post by:
Hello, I am using a ListView connected with an ObjectDataSource. I am creating everything at runtime by implementing the ListView ITemplate. I know I get a one way bind so I need to define my...
0
7199
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
7076
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
1
6984
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
7453
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
1
5005
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...
0
3162
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The...
0
3151
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
732
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
377
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.