Is it just me, or are events just Subs in disguise ??

[Nicky Smith]

Hello,

I'm studying a book on VB.net Win apps, and I'm reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn't this just the same as calling a sub or function?

Forgive me if I'm missing something life changing here, but I just
don't get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

 

[Richard Myers]

Hi Nicky,

Yep you are missing a major point about events and delegates in general.

The beauty of both is that they dont require a "caller". With a traditional
sub the calling procedure has to know the sub exists and call it. With an
event the caller simply registers for the event and has a specified (via a
delegate) method(s) called when something of interest happens.

The pattern is more commonly called Observer/Observable. When you ask why
not just have subs in a class instead of them raising events, then ask
yourself how, when using this method, would a form know when a button a is
clicked.

Using events/delegates the form simply registers for the click event and
then assigns a method (with a signature matching the delegate) to handle
that event, when and/or if it occurs. With the method you suggest of just
using subs, the form would have to continously poll the button to find out
whether it had been clicked or the buttons would have to know the form would
exist at the time of development and know which method within that form to
call when an "event" occurs.

This quickly becomes a complete mess when compared with the de-coupled
elegance of the event driven model.

Delegates are a whole subject area unto themselves. The basics with respect
to events is that they allow any method that matches the delegate signature
and registers for the event to be used to handle the event. With your subs
ideas a developer would have to know every class that would ever be
interested in a specific event when the class is written and know which
method within that class to call in the case of that event. ... which is
extremely complex and wasteful in a small project and impossible n large
projects or with component development.

Delegates are exceptionally powerful in terms of allowing the extension of a
given classes runtime behaviour... in a manner not neccessarily lending
itself to subclassing.... callback methods/asynchronous development etc.

The best way i think for you to discover why events are neccessary is to try
to perform an event driven operation via your subs idea. You'll quickly
discover the benefits of the event driven model.


hth
Richard

 

[Ken Tucker [MVP]]

Hi,

Events run a subroutine based on something happening. If you were
writing a class library you add events to notify the user of something. For
example a class that was periodically checking for email messages would
raise an event when a message is recieved.

Delegates are callback functions. Use them for api callback
functions or something you want to run in the background. For example I
would use a delegate when retrieving large amounts of data from a web
service. This way it can be run the background and not lock up the
computer. Another example would be the enumwindows api call

Ken
----------------

Hello,

I'm studying a book on VB.net Win apps, and I'm reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn't this just the same as calling a sub or function?

Forgive me if I'm missing something life changing here, but I just
don't get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

 

[Nicky Smith]

Hi Nicky,

Yep you are missing a major point about events and delegates in general.

The beauty of both is that they dont require a "caller". With a traditional
sub the calling procedure has to know the sub exists and call it. With an
event the caller simply registers for the event and has a specified (via a
delegate) method(s) called when something of interest happens.

The pattern is more commonly called Observer/Observable. When you ask why
not just have subs in a class instead of them raising events, then ask
yourself how, when using this method, would a form know when a button a is
clicked.

Well, as I said, I do know about, and see the logic in control events.
(buttons and other graphical controls, and non-graphical controls such
as the timer). These are an everyday fact of VB and windows
programming, but the book (MCAD Windows Apps from MSPress) suggests
making a bank account class and raising an event if the account is
overdrawn. namely when the account goes in minus. That type of
behaviour is easly handled by a simple check to the balance when any
activity is generated, ie: adding or withdrawing funds.

To quote the book:

Once an event is declared, you can raise it in code when the
designated event occurs. For example, you might have a component that
represents a bank account, which could raise an Overdrawn event
whenever the balance falls below zero.

Of course there are events in VB, the whole VB system is based on
events, but that statement from the book seems questionable.

I'm starting to think that this may be just a bad example.

 

[Nicky Smith]

Hi,

Events run a subroutine based on something happening. If you were
writing a class library you add events to notify the user of something. For
example a class that was periodically checking for email messages would
raise an event when a message is recieved.

Well wouldn't that just as easily be handled by a sub or a function?

Delegates are callback functions. Use them for api callback
functions or something you want to run in the background. For example I
would use a delegate when retrieving large amounts of data from a web
service. This way it can be run the background and not lock up the
computer. Another example would be the enumwindows api call

Isn't that the same as starting a new thread?

 

[Ken Tucker [MVP]]

Hi,

Events notify the user is something has happened. How would the
main program know the sub or function is running if there is no event.

Delegates are similar to threads. However a delegates unlike
threads can notify you when they are finished.

Ken
------------------

Hi,

Events run a subroutine based on something happening. If you were
writing a class library you add events to notify the user of something.
For
example a class that was periodically checking for email messages would
raise an event when a message is recieved.

Well wouldn't that just as easily be handled by a sub or a function?

Delegates are callback functions. Use them for api callback
functions or something you want to run in the background. For example I
would use a delegate when retrieving large amounts of data from a web
service. This way it can be run the background and not lock up the
computer. Another example would be the enumwindows api call

Isn't that the same as starting a new thread?

 

[Nicky Smith]

Hi,

Events notify the user is something has happened. How would the
main program know the sub or function is running if there is no event.

Fx: psuedo code:

sub checkmail

'mail checking code adds or updates the messages object.


if messages.count > 0 then
msgbox "You've got mail"
end if

end sub

Simple. No need to write or raise an event. Granted, the call to
checkmail would be done through a timer event, but as I have
mentioned, i do understand the implementation of events and event
handlers for the vb components and controls, but I just can't see I
would need to write my own event handlers.

I've written a lot of programs in VB5, 6 and .Net and I've never
needed to 'Raise an event'. Also, I've never seen the point in raising
an error either.

If for example a database connection failed, you can raise an error
which causes an error handler to start (in vb classic this was the
old, On Error Goto and then the error handling code) - but again, this
could be done by displaying a message box and then exiting the sub or
continuing (the same as the Resume Next statement).

Delegates are similar to threads. However a delegates unlike
threads can notify you when they are finished.

No that does sound usefull.

 

[Cor Ligthert]

Nicky,

Thirth try, in additions to the others.

The most simple way to tell why to raise an event is in a multithreading
operation.

Thread A is busy, however Thread B has found there has to be done something
in Thread A which has created Thread B. You have to raise an event because
thread A should first complete the processes he is busy with before he can
handle the event.

Another reason is that when you are using a seperated class than you do not
know the name of the form (or other class) you are using it in.

So in that class you cannot say, If value > 1 then ??????.showmessage. Here
you needs too an event to raise.

In your form you can now instance your object "withevents" and when you make
a sub tell the event that is used by "handles myobject.event1"

In a class itself you have never to raise an event when that is only used in
that class, than you should call the sub or function directly

This is only about the event, because a delegate is not an event however a
pointer to the address of any object in your program, that can be used for
more than only events and I do not like to mix up two things.

I hope this gives some idea's

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Nicky,
In addition to the other comments.

You are correct Event handlers are subs in disguise.

You are missing 2 very important points about Events.

1. They decouple the code that is being notified from the code doing the
notification. In Bank Account sample, the bank account can raise an event
that says it is overdrawn. The form that is displaying the bank account can
handle this event and either display a message box or put a message in the
status bar or what ever. The form itself takes care of the UI, while the
Bank Account does its business (separates your application into
Domain(Business) and Presentation(UI).)

2. They allow multiple handlers of the event. In the Bank Account sample,
the Bank object (that owns all Bank Accounts) could handle the overdrawn
event and add a overdraft fee transaction to the Bank Account, the Bank
Account Detail Form displaying the Bank Account can display an item specific
message, the Bank Account Summary Form could change the display of the item
to.


The reason your class adds an event is EXACTLY the same reason you would add
the Click event to a form. Just as the Click event of a button allows your
Form to handle a button being clicked, so does the Overdrawn event on
BankAccount, it allows another object do what needs to be done when the bank
account is overdrawn. Rather then rely on the Bank Account doing the right
thing. What happens when the Bank Account is used in a Windows Service
(Messagebox not available) and its used in a Windows Form (MessageBox
available) and its used in a Web Form (MessageBox not available) and its
used ...

Hope this helps
Jay

 

[Jeff Johnson]

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

Event: Your telephone rings.

Event handler: You answer the phone...or you don't.

Imagine if the phone were designed to "pick up" as soon as it rang. You
would no longer be given a choice of whether to answer or not. This is why
you define events in components. It gives a consumer of your product the
ABILITY to handle the event if it so desires.

Now you may be designing components which are for your use and your use
only. You know that EVERY TIME a certain condition occurs, you want to do
something about it, so my example of choosing to handle the event or not
doesn't apply to you. In this case, events aren't absolutely necessary, but
if you encounter the condition in component A and you want to run code in
form B, you're going to have to make the Sub/Function in form B available to
the rest of your project (i.e., have at least Friend visibility). Worse, if
you may have multiple occurrences of form B (each of which instantiates a
component A), you'll have to provide a mechanism to keep track of which form
B this particular instance of component A relates to. Events greatly
simplify this, because any instance of form B just needs to hook up its
handler to its component A's event.

 

[Nicky Smith]

On Sat, 18 Sep 2004 23:35:48 +0200, Nicky Smith <[email protected]>
wrote:


Thanks to everyone who commented on this post. I think the penny has
dropped!

The book did indeed over simplify the use of user-defined events and
event handlers. The examples given could just as easily be handled by
simple conditional statements and calls to subs or functions.

But, it did go on to describe more complex scenarios and the Lab
chapter at the end used an event and event handler to demonstrate
events being fired in a component class, and en event handler updating
member variables in a form and their display in text box controls.

In fact, it did do many of the things you guys have described in your
explanations.

Your comments have helped me better understand the later chapters.

Thanks for your help,

N.

 

[Wild Wind]

Fx: psuedo code:

sub checkmail

'mail checking code adds or updates the messages object.


if messages.count > 0 then
msgbox "You've got mail"
end if

end sub

But by this, you are suggesting that the only way to
know whether you've got mail is to call checkmail repeatedly.

Would it not be more efficient to get the messages object
to raise an event *once* instead of calling checkmail
several times?