Events v. Delegates

[Siegfried Heintze]

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 uses the "WithEvents " and events.
There is another example on page 124 that shows how to use delegates to sort
an array.

I don't understand the difference between events and delegates. Are they
redundant features? How do I decide which to use?

Thanks,
Siegfried

[Mr. Arnold]

Re: Events v. Delegates


"Siegfried Heintze" <siegfried@hein tze.comwrote in message
news:O%23lKVjDF IHA.6120@TK2MSF TNGP05.phx.gbl. ..

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 uses the "WithEvents " and
events. There is another example on page 124 that shows how to use
delegates to sort an array.
>
I don't understand the difference between events and delegates. Are they
redundant features? How do I decide which to use?

This link should help you with events and delegates.

http://www.informit.com/articles/article.aspx?p=23020&rl=1

[ge0193387@otc.edu]

Re: Events v. Delegates

On Oct 21, 6:19 pm, "Siegfried Heintze" <siegfr...@hein tze.comwrote:

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 uses the "WithEvents " and events.
There is another example on page 124 that shows how to use delegates to sort
an array.
>
I don't understand the difference between events and delegates. Are they
redundant features? How do I decide which to use?
>
Thanks,
Siegfried

They're not necessarily redundant features. Withevents is the easy
way to wire up events within VB.Net and delegates and other things are
another way to wire up events in just .Net (C# is one that I know of
for sure). Wiring up events in C# is probably one of the things that
could be made easier.

As for deciding which to use, withevents is for something you plan to
use as a global variable throughout the entire code (since it has to
be a global variable), delegates will be used more for declaring
dynamic controls/objects so you can wire up the correct event at the
right time.

[=?Utf-8?B?VGVycnk=?=]

RE: Events v. Delegates

Hi,
While I am fairly new to all this and am still on the 'learning curve',
here is how I understand it. You can think of delegates as what events use
behind the scene. When you use the delegate keyword, you are declaring a
type (of pointer to a method).
eg Delegate Function Foo(ByVal I As Integer) As Integer
then you can instansiate a member of this type like...
Dim MyFoo As Foo = AddressOf DoSomething
solong as DoSomething is a Function that takes 1 integer argument and
returns an integer.
This is also how you accomplish 'callbacks'. A method can accept a
parameter which is declared as a 'delegate' type. eg
Sub TestRoutine(byv al MyCallback as Foo)
.....
Dim Result as Integer = MyCallBack(Some Int)
.....

Now, as I understand it, 'Events' are just that - 'CallBacks'. So, when you
'wire' a routine to an event, you are 'adding' that routines address to the
list of routines that are to be called when that event fires. Remember that
the routine you are trying to wire to the control has to have a particular
signature (ie match the delegate type that the controll expects to
'callback').

Well, I am sure there is more to this that I don't understand, but hopefully
I have not said anything that is not true. If I have I, I invite someone to
straigten me out on this.

--
Terry


"Siegfried Heintze" wrote:

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 uses the "WithEvents " and events.
There is another example on page 124 that shows how to use delegates to sort
an array.
>
I don't understand the difference between events and delegates. Are they
redundant features? How do I decide which to use?
>
Thanks,
Siegfried
>
>
>

[Siegfried Heintze]

Re: Events v. Delegates

I wrote the program below twice to teach myself about events and delegates. This is the second version that uses delegates instead of events (but I left the events in delegates).
Are the following statements true for delegates instead of events?
(1) The delegate strategies don't use WithEvents
(2) Delegates must be declared (but so must events so this is a wash)
(3) Delegates don't work with the keyword "handles" and must have a seperate statement where they are added
(4) Delegates require an extra function parameter so we know who to call back
(5) We have to explicitly pass the delegate using the AddressOf feature which I find to be more cryptic than events
(6) Delegates must be called specifically and don't work with the RaiseEvent keyword (I assume, I did not try it)
(7) The delegate syntax gets really painful if you want use the multicast feature, unlike events where you just use the "handles" keyword on multiple functions.

It looks to me like events were invented mostly for VB. In the Case of C#, there is no handy "handles" statement and you have to explicitly add the event in the constructor (typically using the "+=" operator). Also, C# has no "RaiseEvent " keyword so raising an event and calling a delegate are identical.

Now how would I modify this so there could me multiple listener functions called by line 26 (without modifying line 26, of course)?

Thanks,
Siegfried


Imports Microsoft.Visua lBasic.DateAndT ime

Public Class DelegateTimer

Private mText As New TimerState

'Private WithEvents mText As TimerState = New TimerState

Private Sub mText_UpdateTim e(ByVal Jump As Double) 'Handles mText.UpdateTim e

lblDisplayTime. Text = Microsoft.Visua lBasic.Format(J ump, "##0.00")

Application.DoE vents()

End Sub

Private Sub mText_UpdateTim e2(ByVal Jump As Double) 'Handles mText.UpdateTim e

System.Threadin g.Thread.Sleep( 100)

End Sub

Private Sub btnStart_Click( ByVal sender As System.Object, ByVal e As System.EventArg s) Handles btnStart.Click

Dim d1 As New TimerState.Upda teTimeDele(Addr essOf mText_UpdateTim e)

Dim d2 As New TimerState.Upda teTimeDele(Addr essOf mText_UpdateTim e2)

Dim dlgt As TimerState.Upda teTimeDele

dlgt = CType([Delegate].Combine(d1, d2), TimerState.Upda teTimeDele)

mText.TimerTask (dlgt, 9.84)

' mText.TimerTask (9.84)

End Sub

End Class

Class TimerState

'Public Event UpdateTime(ByVa l Jump As Double)

Delegate Sub UpdateTimeDele( ByVal Jump As Double)

Public Sub TimerTask(ByVal CallBack As UpdateTimeDele, ByVal Duration As Double)

Dim Start As Double

Dim SoFar As Double

Start = Microsoft.Visua lBasic.DateAndT ime.Timer

SoFar = Start

Do While Timer < Start + Duration

If Microsoft.Visua lBasic.DateAndT ime.Timer - SoFar >= 0.1 Then

SoFar = SoFar + 0.1

'RaiseEvent UpdateTime(Time r - Start)

'CallBack.Invok e(Timer - Start)

CallBack(Timer - Start)

End If

Loop

End Sub

End Class

[Siegfried Heintze]

Re: Events v. Delegates

I meant to say I left the events in comments, not delegates.

Also, remove "Now how would I modify this so there could me multiple
listener functions called by line 26 (without modifying line 26, of
course)?" as I did that.

[Armin Zingler]

Re: Events v. Delegates

"Siegfried Heintze" <siegfried@hein tze.comschrieb

I wrote the program below twice to teach myself about events and
delegates. This is the second version that uses delegates instead of
events (but I left the events in delegates).
Are the following statements true for delegates instead of events?
(1) The delegate strategies don't use WithEvents

Right

(2) Delegates must be declared (but so must events so this is a
wash)
(3) Delegates don't work with the keyword "handles" and must have
a seperate statement where they are added

Added to what?

(4) Delegates require an extra function parameter so we know who to
call back

No. The Delegate already knows what to call if you call the delegate. A
delegate does not need function parameters. The signature (number and type
of parameters) of the delegate's and the target must be the same. Can also
be 0.

(5) We have to explicitly pass the delegate using the AddressOf
feature which I find to be more cryptic than events

Events are based on delegates. The target of an event handler must also be
determined by using AddressOf.

(6) Delegates must be called specifically and don't work with the
RaiseEvent keyword (I assume, I did not try it)

Raiseevent internally calls all the delegates attached to the event.

(7) The delegate syntax gets really painful if you want use the
multicast feature, unlike events where you just use the "handles"
keyword on multiple functions.

It looks to me like events were invented mostly for VB.

No. It's an OOP concept.

In the Case
of C#, there is no handy "handles" statement and you have to
explicitly add the event in the constructor (typically using the
"+=" operator).

Right, but a lack of the keyword in C# doesn't say that it has been made for
VB.

Also, C# has no "RaiseEvent " keyword so raising an
event and calling a delegate are identical.

No, events are implemented in the .Net framework. Just the syntax in raising
the event is different.

Now how would I modify this so there could me multiple listener
functions called by line 26 (without modifying line 26, of course)?

I'm not sure what you mean. If the event is declared an you use RaiseEvent,
the event is raised and every event handler is called.



Maybe you think too complicated:
- Events are a concept. Delegates are used to implement the concept.
- Internally, declaring an event means maintaining a list of delegates.
RaiseEvent internally calls all delegates in the list.



"WithEvents " and "Handles" is just and "add-on" but the concepts behind stay
the same. Declaring a WithEvents variable internally creates a property. So,
these two versions are exactly the same:



version A:

Dim WithEvents btnStart As Button

Private Sub btnStart_Click( _
ByVal sender As System.Object, ByVal e As System.EventArg s) _
Handles btnStart.Click

End Sub




version B:

Private _btnStart As Button

Property btnStart() As Button
Get
Return _btnStart
End Get
Set(ByVal value As Button)
If _btnStart IsNot Nothing Then
RemoveHandler _btnStart.Click , AddressOf btnStart_Click
End If
_btnStart = value
If _btnStart IsNot Nothing Then
AddHandler _btnStart.Click , AddressOf btnStart_Click
End If
End Set
End Property


Private Sub btnStart_Click( _
ByVal sender As System.Object, ByVal e As System.EventArg s)

End Sub


WithEvents and Handles just simplify the process of dynamically
adding/removing event handlers to the object currently assigned to a
variable. (and for historic reasons in previous VB versions)


Armin

[CMoya]

Re: Events v. Delegates

WithEvents/Handles are just a more "declarativ e" way to handle events. It's
as simple as that. It's not so much redundant as it is a language feature
(and a very good one). You don't have to worry about removing or tearing
down event handlers... it's all done for you.

When you start actually creating your own custom events in your classes, you
may find that creating delegates that inherit from EventHandler to define
your parameters is helpful. From what I heard long ago, it also helps
performance.
So instead of
Public Event MyCustomEvent(s ender As Object, e as System.EventArg s)
You simply do
Public Event MyCustomEvent as EventHandler 'or create your own delegate
based on EventHandler


--
-C. Moya

http://www.cmoya.com

"Siegfried Heintze" <siegfried@hein tze.comwrote in message
news:O%23lKVjDF IHA.6120@TK2MSF TNGP05.phx.gbl. ..

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 uses the "WithEvents " and
events. There is another example on page 124 that shows how to use
delegates to sort an array.
>
I don't understand the difference between events and delegates. Are they
redundant features? How do I decide which to use?
>
Thanks,
Siegfried
>