C# - Events

  • Thread starter Thread starter Richard
  • Start date Start date
R

Richard

Hi,


I'm pretty new to C# and only have 6months with vb.net. However my question
regards C# and events.

Basically I've a class which uses a number of events to inform the main
application when certain conditions are met. The events work spot-on, so
long as I've typed all the event types into my main app.


e.g. The Class has;
public delegate void Connected(bool bConnected);
public event Connected ConnectedEvent;


Within my main application i then create a variable called "boo" e.g.

clsBoo boo = new clsBoo();

I then create the event;

Boo.ConnectedEvent += new Playabout.clsBoo.Connected(oo_ConnectedEvent);

I then have to type the actual interface like so

private void boo_ConnectedEvent(bool bConnected)
{
MessageBox.Show("Are we connected? " + bConnected.ToString());
}

Having to do the above seems very lengthy and requires that you know the
design of the event e.g. what's going to be placed between the brackets. In
visual basic and vb.net, as soon as I create a variable and assign a class
to it, all the events are automatically populated within the IDE. Why doesn
't C# do this?

If I never knew the design of the event coming from say a C# dll, then how
would I be expected to know all the events within the dll?

I've also noticed that if I don't code all the events listed within the c#
class I've created, then the class will raise an error when it attempts to
call it.

Hoping that someone can clear this up for me.



Thanks
 
I can help with the last point, first.

Inside the class you created, the convention for calling event handler
delegates is this:

if (this.ConnectedEvent != null)
{
this.ConnectedEvent(this.isConnected);
}

or something similar. Note that you always test the event delegate
chain against "null" first to see if you should call it. Yes, it's
annoying, but that's the way it works.

That way your code won't fail when you have no subscribers to an event.

(By the way, even this example violates the standard for event
handlers: that the first parameter is the object that generated the
event, and the second parameter is derived from the System.EventArgs
class.)

Second, the C# IDE _does_ help you write event handler methods. In you
client class, when you say,

Boo.ConnectedEvent +=

the IDE _does_ offer you the option of filling in the "new Connected("
part automatically, and then offer you the option of automatically
creating a method and filling its name into the line you're typing. All
you have to do is press Tab twice.
 
(By the way, even this example violates the standard for event
handlers: that the first parameter is the object that generated the
event, and the second parameter is derived from the System.EventArgs
class.)
Click to expand...

While I agree with most C#/.NET conventions, this one is really silly.
For many events, the sender is irrelevant - and as for EventArgs, I
frankly don't see the point. Really, what benefit does EventArgs give
over having a strongly-typed argument type which doesn't need to derive
from EventArgs? Given that delegates (currently, at least) have to
*exactly* match the arguments, I really can't see any benefit - it's
not like you can use a more general event handler for specific events.

Personally I usually make my events (certainly outside GUIs) take the
relevant arguments only - if that includes the sender, so be it. Often
there's no useful argument at all - in which case there's no point in
having a parameter in the first place.
 
I agree... I can't see a good reason for that convention, either.
However, I prefer to follow conventions unless I can think of a good
reason _not_ to follow them. Call me a slave to fashion. :)
 
Bruce Wood said:
I agree... I can't see a good reason for that convention, either.
However, I prefer to follow conventions unless I can think of a good
reason _not_ to follow them. Call me a slave to fashion. :)
Click to expand...

The reason not to follow this one is that it limits all your parameter
classes to be derived from EventArgs. If you just want to pass a
string, you need to derive a new class from EventArgs which has a
string. If you want to pass something else, you need another new class.
I find I often already *have* an object with the right properties etc,
and want to just pass that - and there's no compelling reason to make
that derive from EventArgs (and often it can't, if it's already
deriving from something else).
 
Richard,
Like Bruce said, I have the IDE generate my event handler methods for
me by pressing TAB twice after +=. Coming from VB.Net, you will
certainly find that you have to do a _little_ more typing, but I don't
see that as a problem.

Jon,
You make a good argument. I, too, find it painful to have to create
EventArgs classes every time I need a new event parameter.

Best regards,
Jeffrey Palermo
http://www.jeffreypalermo.com
 
Back
Top