consolidating my events

[Guest]

hey all,

protected void Calendar1_VisibleMonthChanged(object sender,
MonthChangedEventArgs e)
{
OnBubbleClick(e);
}
protected void Calendar1_SelectionChanged(object sender, EventArgs e)
{
OnBubbleClick(e);
}
}

is there a way to make this just one procedure/method?

thanks,
rodchar

 

[Jon Skeet [C# MVP]]

protected void Calendar1_VisibleMonthChanged(object sender,
MonthChangedEventArgs e)
{
OnBubbleClick(e);
}
protected void Calendar1_SelectionChanged(object sender, EventArgs e)
{
OnBubbleClick(e);
}
}

is there a way to make this just one procedure/method?

That depends on two things:

1) Are you using C# 2? If you're still stuck with C# 1, then no.
2) Is OnBubbleClick overloaded, with one version accepting EventArgs
and the other accepting MonthChangedEventArgs? If so, you've got two
different calls there.

If you're using C# 2 and there's only one OnBubbleClick method, then
you can get rid of Calendar1_VisibleMonthChanged, and just use
Calendar1_SelectionChanged for both handlers.

 

[Nicholas Paldino [.NET/C# MVP]]

rodchar,

You can declare this:

private void BubbleClickEventHandler(object sender, EventArgs e)
{
// Call OnBubbleClick.
OnBubbleClick(sender);
}

And then assign that to the VisibleMonthChanged event handler on
Calendar1, and the SelectionChanged event on Calendar1. The reason you can
do that is because of covariance (or contravariance, I forget which it is)
on delegates. I removed the EventArgs instance from OnBubbleClick because
you will only ever get an EventArgs instance through that method (which is
what enables the covariance/contravariance), and EventArgs doesn't have any
useful information, so I omitted it. In it's place, I put the sender, which
might be relevant.

Note that when doing this, you are going to have to deal with the lowest
common denominator between the two, meaning, EventArgs (instead of
MonthChangedEventArgs).

 

[Peter Duniho]

[...]
Note that when doing this, you are going to have to deal with the lowest
common denominator between the two, meaning, EventArgs (instead of
MonthChangedEventArgs).

Unless, of course, the OnBubbleClick method includes some conditional
logic, testing the actual type of the EventArgs instance (which would of
course have to be passed in) and doing something different depending on
the type.

I'd say that if that were the case, it's a likely argument in favor of
keeping two different event handlers. But it could happen.

Pete

 

[Jon Skeet [C# MVP]]

[...]
Note that when doing this, you are going to have to deal with the lowest
common denominator between the two, meaning, EventArgs (instead of
MonthChangedEventArgs).

Unless, of course, the OnBubbleClick method includes some conditional
logic, testing the actual type of the EventArgs instance (which would of
course have to be passed in) and doing something different depending on
the type.

I'd say that if that were the case, it's a likely argument in favor of
keeping two different event handlers. But it could happen.

But in that case the original code would be broken in the same way, as
both handlers originally called OnBubbleClick. The only situation in
which the two handlers could be logically different is where there's
one OnBubbleClick (MonthChangedEventArgs e) method and one
OnBubbleClick(EventArgs e) method - in other words where the *compiler*
has the conditional logic.

 

[Peter Duniho]

But in that case the original code would be broken in the same way, as
both handlers originally called OnBubbleClick.

Sorry, I don't really understand your reply. I didn't say anything was
broken, so I'm not sure what it means for something to "be broken in the
same way". In the same way as what?

I agree that with respect to the posted code, either you have two
different ObBubbleClick methods (overloaded) or a single one. But that
doesn't change the fact that you could in fact consolidate that logic
into a single method. In fact, trivially:

protected void Calendar1_SelectionChanged(object sender, EventArgs e)
{
MonthChangedEventArgs mce = e as MonthChangedEventArgs;

if (mce != null)
{
OnBubbleClick(mce);
}
else
{
OnBubbleClick(e);
}
}

works fine as well (assuming OnBubbleClick is overloaded).

I don't intend to say that any of these methods is necessarily _better_,
simply that they also work and for the original question, which asked
simply whether a single event handler can be written, it's a correct
solution.

Nicholas wrote that the OP would "HAVE to deal with the lowest common
denominator" [emphasis mine], and it was to that which I was responding.
It may be true that alternatives to dealing with the lowest common
denominator have no real advantage to just having two event handling
methods in the first place, but that's not the same as saying it can't
be done.

Pete

 

[Jon Skeet [C# MVP]]

Sorry, I don't really understand your reply. I didn't say anything was
broken, so I'm not sure what it means for something to "be broken in the
same way". In the same way as what?

Don't worry - I misread your previous post.

I agree that with respect to the posted code, either you have two
different ObBubbleClick methods (overloaded) or a single one. But that
doesn't change the fact that you could in fact consolidate that logic
into a single method. In fact, trivially:

protected void Calendar1_SelectionChanged(object sender, EventArgs e)
{
MonthChangedEventArgs mce = e as MonthChangedEventArgs;

if (mce != null)
{
OnBubbleClick(mce);
}
else
{
OnBubbleClick(e);
}
}

works fine as well (assuming OnBubbleClick is overloaded).

That may still not work quite as intended, as that makes the decision
at runtime rather than at compile-time. It's possible that the
EventArgs handler would have been called before, but with a
MonthChangedEventArgs argument, thus then calling OnBubbleClick
(EventArgs) with a MonthChangedEventArgs. It's impossible to replicate
that behaviour without two separate handlers.

However, let's hope that it's not the case