EventHandling problem : Java has solution but what about Microsoft???

[Mahesh Devjibhai Dhola [MVP]]

Hi,
I have added few of the events in some control, example code is:
btnControl.GotF ocus +=new EventHandler(Ev entHandlingMeth od);
btnControl.Clic k +=new EventHandler(Ev entHandlingMeth od);
lblControl.Clic k +=new EventHandler(Ev entHandlingMeth od);

private void EventHandlingMe thod(object sender, EventArgs e)
{
.......
}

btnControl = Button object, lblControl = Lable object

Now the problem is: I am adding the same event handler method in all events for btnControl and lblControl too.

now in EventHandlingMe thod method, i can find which control is using sender but now if i want to put some switch cases in the method for Event Name then I have no any such information in the eventargs or anyother way....

Can someone help/guide me to get the event name?

Is it possible? if yes then how? If no, then any work around?

Thanks in Advance

Regards,
Mahesh Devjibhai Dhola

[Danny Tuppeny]

Mahesh Devjibhai Dhola [MVP] wrote:

The Microsoft Event handling framework allows me to do this what you suggest
but some time, its possible to have such requirement so its not the matter
of sense but its my need so if you can suggest me the woraround for my
prolme then it will be helpful to me.

It doesn't make sense, but you could create a method called from all
event handlers, eg.

void GlobalHandler(o bject sender, string command, EventArgs e)
{
// your code here
}

and hook them up like this:

void button1_click(o bject sender, EventArgs e)
{
GlobalHandler(s ender, "Click", e);
}

But I agree with the other posts - it's stupid. If you're doing the same
thing, you wouldn't need the string. If you're doing different things,
they should be in seperate methods.

[jmcgrew]

This design seems strange to me too, but I'll take your word that it
makes sense for your project. ;)

This seems like a good time to use C# 2.0's anonymous delegates. If
your event handling method doesn't need to have the standard event
signature, you could do something like this...
private void EventHandlingMe thod(string eventName, object sender,
EventArgs e)
{
...
}

btnControl.GotF ocus += delegate(object s, EventArgs e) {
EventHandlingMe thod("GotFocus" , s, e); };
btnControl.Clic k += delegate(object s, EventArgs e) {
EventHandlingMe thod("Click", s, e); };
Now, if you do need to use the standard event signature, you could
create a new EventArgs class that includes a name, stuff the event name
in there, and pass that in as the e parameter:
class NamedEventArgs : EventArgs {
NamedEventArgs( string name, EventArgs inner) { ... }
public string Name { get ... }
public EventArgs InnerArgs { get ... }
}

private void EventHandlingMe thod(object sender, EventArgs e)
{
string name;
NamedEventArgs nea = e as NamedEventArgs;
if (nea != null) {
name = nea.Name;
e = nea.Inner;
} else {
name = "???";
}
...
}

btnControl.GotF ocus += delegate(object s, EventArgs e) {
EventHandlingMe thod(s, new NamedEventArgs( "GotFocus", e)); };
btnControl.Clic k += delegate(object s, EventArgs e) {
EventHandlingMe thod(s, new NamedEventArgs( "Click", e)); };
Jesse

[Lasse Vågsæther Karlsen]

Mahesh Devjibhai Dhola [MVP] wrote:

Dear,
Your design is good or bad, it depends on requirement.

<snip>

If the "good" design needs an ugly hack to implement, it's not a good
design, regardless of how possible it is in other frameworks.

In this case your only option that I know of would be to access the
stack trace of the methods that called you and look at the method names
there. Ie. if you find "OnClick", it's a click event, and so on.

This is an ugly hack, and depending on access permissions the software
is to run under might not be possible anyway.

The data that is sent to the .NET event handlers carry no information
about what event was triggered that ended up in this method call.

I see this case as designing that cars can fly, calling it a good design
and then later on struggle to figure out how on earth this would be
possible.

It isn't.

Change your design.

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vk arlsen.no
PGP KeyID: 0x2A42A1C2

[Danny Tuppeny]

Lasse Vågsæther Karlsen wrote:

In this case your only option that I know of would be to access the
stack trace of the methods that called you and look at the method names
there. Ie. if you find "OnClick", it's a click event, and so on.

A bit off-topic, but is it possible to programatically get a stack
trace? I've had to do it once (in a test app, so not important how ugly
it was), and resorted to throwing an exception just to get the
StackTrace. I assume there's a nicer away - probably in
System.Diagnost ics somwhere?

[Stefan Simek]

Danny Tuppeny wrote:

Lasse Vågsæther Karlsen wrote:

In this case your only option that I know of would be to access the
stack trace of the methods that called you and look at the method
names there. Ie. if you find "OnClick", it's a click event, and so on.

A bit off-topic, but is it possible to programatically get a stack
trace? I've had to do it once (in a test app, so not important how ugly
it was), and resorted to throwing an exception just to get the
StackTrace. I assume there's a nicer away - probably in
System.Diagnost ics somwhere?

There are the System.Diagnost ics.StackTrace/StackFrame classes, but
using them is the ugliest hack I can possibly imagine. And it would not
help at all, because you would only get the name of method that fired
the event (in the better case, might be as well the optimizer inlines
the method and you get the method that called the event-firing method),
which, unless you use the OnXxx convention would not help at all. And,
of course, I expect it to be terribly slow.

Just my 2c.

Stefan

[Danny Tuppeny]

Stefan Simek wrote:

There are the System.Diagnost ics.StackTrace/StackFrame classes, but
using them is the ugliest hack I can possibly imagine. And it would not
help at all, because you would only get the name of method that fired
the event (in the better case, might be as well the optimizer inlines
the method and you get the method that called the event-firing method),
which, unless you use the OnXxx convention would not help at all. And,
of course, I expect it to be terribly slow.

Just my 2c.

Cool. Don't worry, I'm not planning on using it in any "proper"
software, but it might come in handy when writing apps to test apps (if
a test fails, an exception might not be thrown, but it'd be nice to have
the route through the code) :-)

[Truong Hong Thi]

>Don't worry, I'm not planning on using it in any "proper"

software

It could be useful in some "proper" software. For example, you write a
logging framework that allows outputting of the method/class name in
the logged message. You could use the Stack to get the name of the
method that call the log routine. Without Stack, I don't know any other
way to get the MethodBase representing the caller method.

[Mahesh Devjibhai Dhola [MVP]]

Thanks dude,
I am not using .Net 2.0 currently in production environment but i will keep
your solution in my mind.

Thanks for the concern.

<jm*****@gmail. com> wrote in message
news:11******** *************@g 14g2000cwa.goog legroups.com...

This design seems strange to me too, but I'll take your word that it
makes sense for your project. ;)

This seems like a good time to use C# 2.0's anonymous delegates. If
your event handling method doesn't need to have the standard event
signature, you could do something like this...
private void EventHandlingMe thod(string eventName, object sender,
EventArgs e)
{
...
}

btnControl.GotF ocus += delegate(object s, EventArgs e) {
EventHandlingMe thod("GotFocus" , s, e); };
btnControl.Clic k += delegate(object s, EventArgs e) {
EventHandlingMe thod("Click", s, e); };
Now, if you do need to use the standard event signature, you could
create a new EventArgs class that includes a name, stuff the event name
in there, and pass that in as the e parameter:
class NamedEventArgs : EventArgs {
NamedEventArgs( string name, EventArgs inner) { ... }
public string Name { get ... }
public EventArgs InnerArgs { get ... }
}

private void EventHandlingMe thod(object sender, EventArgs e)
{
string name;
NamedEventArgs nea = e as NamedEventArgs;
if (nea != null) {
name = nea.Name;
e = nea.Inner;
} else {
name = "???";
}
...
}

btnControl.GotF ocus += delegate(object s, EventArgs e) {
EventHandlingMe thod(s, new NamedEventArgs( "GotFocus", e)); };
btnControl.Clic k += delegate(object s, EventArgs e) {
EventHandlingMe thod(s, new NamedEventArgs( "Click", e)); };
Jesse

[John A. Bailo]

You should be looking at multicast delegates as an interface for your
events.
Mahesh Devjibhai Dhola [MVP] wrote:

Hi,
I have added few of the events in some control, example code is:

/btnControl.GotF ocus +=new EventHandler(Ev entHandlingMeth od);
btnControl.Clic k +=new EventHandler(Ev entHandlingMeth od);
lblControl.Clic k +=new EventHandler(Ev entHandlingMeth od);/

/private void EventHandlingMe thod(object sender, EventArgs e)
{
.......
}/

/btnControl = Button object, lblControl = Lable object/

/Now/ the problem is: I am adding the same event handler method in all
events for btnControl and lblControl too.

now in EventHandlingMe thod method, i can find which control is using
sender but now if i want to put some switch cases in the method for
Event Name then I have no any such information in the eventargs or
anyother way....

Can someone help/guide me to get the event name?

Is it possible? if yes then how? If no, then any work around?

Thanks in Advance

Regards,
Mahesh Devjibhai Dhola

[Stefan Simek]

Truong Hong Thi wrote:

Don't worry, I'm not planning on using it in any "proper"
software

It could be useful in some "proper" software. For example, you write a
logging framework that allows outputting of the method/class name in
the logged message. You could use the Stack to get the name of the
method that call the log routine. Without Stack, I don't know any other
way to get the MethodBase representing the caller method.

Maybe, but there's still the problem I have mentioned in my previous
post. If your calling method gets inlined (I agree it won't happen too
often, at least for non-trivial methods, but who knows how the JIT will
behave in future versions?), you get the caller of the calling method
which can be misleading.