By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,110 Members | 1,541 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,110 IT Pros & Developers. It's quick & easy.

Naming convention for delegates, events and event handlers?

P: n/a
I'm trying to pin down a good naming convention for the 3 things
required to implement an event.

You need:
1) a delegate
2) an event
3) an event handler

Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.

Cheers

Boz

delegate void DataAvailableEventHandler(string data);

class ServerClass
{
public event DataAvailableEventHandler DataAvailable;

public FireEvent()
{
if (DataAvailable != null)
{
DataAvailable("bang");
}
}
}

class ClientClass
{
public ClientClass(ServerClass server)
{
server.DataAvailable += new
DataAvailableEventHandler(ServerClass_DataAvailabl e);
}

private ServerClass_DataAvailable(string data)
{
Trace.WriteLine("I got some data:\n" + data);
}
}

Jan 16 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Boz,

#3 isn't so important, because that is a private implementation, and the
naming conventions don't deal with private members (after all, they are
private, and not exposed).

You have the naming conventions right for 1 and 2. The only thing I
would say is that your event handler should follow the pattern for events
already established.

This means that you have two parameters. The first is of type object,
named sender, which is the instance of the object that fired the event.

The second is a class that derives from EventArgs (or EventArgs itself,
if there is no extra information).

In this case, you would have a class named DataAvailableEventArgs which
exposes a property named Data, which would expose your string.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<jj********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I'm trying to pin down a good naming convention for the 3 things
required to implement an event.

You need:
1) a delegate
2) an event
3) an event handler

Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.

Cheers

Boz

delegate void DataAvailableEventHandler(string data);

class ServerClass
{
public event DataAvailableEventHandler DataAvailable;

public FireEvent()
{
if (DataAvailable != null)
{
DataAvailable("bang");
}
}
}

class ClientClass
{
public ClientClass(ServerClass server)
{
server.DataAvailable += new
DataAvailableEventHandler(ServerClass_DataAvailabl e);
}

private ServerClass_DataAvailable(string data)
{
Trace.WriteLine("I got some data:\n" + data);
}
}

Jan 16 '06 #2

P: n/a
<jj********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I'm trying to pin down a good naming convention for the 3 things
required to implement an event.


FxCop has a setting where you can audit your naming conventions.

If you don't have it you can get it at

http://www.gotdotnet.com/team/fxcop/

-- Alan
Jan 16 '06 #3

P: n/a
Hello Boz

Not sure you're aware of it, but the 2.0 framework provides a generic
EventHandler.

public event EventHandler<DataAvailableEventArgs> DataAvailable;

I recently refactored a framework for 2.0 and replaced all
eventhandler-specific delegates with the generic 2.0 pattern as seen above.

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)
Jan 16 '06 #4

P: n/a
Thanks for the tip on EventArgs. I'd heard that before and will change
my delegate to follow the conventions.

Cheers

Boz

Jan 16 '06 #5

P: n/a
That looks very handy.

Cheers

Boz

Jan 16 '06 #6

P: n/a
We're not sure we can move to .NET 2.0 yet, but if we do we'll make use
of generics where possible.

Regards

Boz

Jan 16 '06 #7

P: n/a
jj********@yahoo.com wrote:
Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong. Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.
I'm not really going to comment on the naming, but:
class ServerClass
{
public event DataAvailableEventHandler DataAvailable;

public FireEvent()
{
if (DataAvailable != null)
{
DataAvailable("bang");
}


Wrong wrong wrong! There is no difference between your

public event DataAvailableEventHandler DataAvailable;

and a

public /*event*/ DataAvailableEventHandler DataAvailable;

That is, DataAvailable is basically a public delegate field, and any
code that sees ServerClass can fire the DataAvailable event and/or
edit the invovation list.

You should be using code like

class ServerClass
{
private event DataAvailableEventHandler dataAvailable;
// Only ServerClass can touch the delegate!

public event DataAvailableEventHandler DataAvailable
// external code can only subscribe/unsubscribe
{
add {dataAvailable += value;}
remove {dataAvailable -= value;}
}

public void FireEvent()
{
if (dataAvailable != null)
{
dataAvailable("bang");
}
}
}

--
<http://www.midnightbeach.com>
Jan 16 '06 #8

P: n/a
As good as that code is, if you try using his method and firing the
event, it wont let you (at least in 2.0 it wont let you).
You should be using code like

class ServerClass
{
private event DataAvailableEventHandler dataAvailable;
// Only ServerClass can touch the delegate!

public event DataAvailableEventHandler DataAvailable
// external code can only subscribe/unsubscribe
{
add {dataAvailable += value;}
remove {dataAvailable -= value;}
}

public void FireEvent()
{
if (dataAvailable != null)
{
dataAvailable("bang");
}
}
}

Jan 17 '06 #9

P: n/a
Ok, I'm confused. Why can't you protect access to event delegate in
..NET 2.0? It makes sense and follows the property/field mechanism.

Boz

Jan 17 '06 #10

P: n/a
Mark Ingram wrote:
As good as that code is, if you try using his method and firing the
event, it wont let you (at least in 2.0 it wont let you).


Aack, you're right! I've been misunderstanding the "event DelegateType
EventName" syntax - noticed that *in class* it acts like a delegate.
Did *not* notice that out-of-class it acts like add/remove delegate.

Thanks!

--
<http://www.midnightbeach.com>
Jan 17 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.