Casting of Object to Button

  • Thread starter Thread starter br
  • Start date Start date
B

br

I have the following Click event handler

//Click event
public void ProcessClick (Object aoSender, EventArgs
aoArgs)
{
MessageBox.Show ("Clicked on " + ((Button)
aoSender).Tag.ToString());
}


and when I compile I get the following error
"error CS0029: Cannot implicitly convert type 'object'
to 'System.Windows.Forms.Button'

What am I doing wrong here?
Thanks
 
br said:
I have the following Click event handler

//Click event
public void ProcessClick (Object aoSender, EventArgs
aoArgs)
{
MessageBox.Show ("Clicked on " + ((Button)
aoSender).Tag.ToString());
}


and when I compile I get the following error
"error CS0029: Cannot implicitly convert type 'object'
to 'System.Windows.Forms.Button'

What am I doing wrong here?

There's nothing wrong with the code you posted - are you sure the
compiler is complaining about that line?
 
br said:
What am I doing wrong here?

Nothing. However, as an alternative you might consider this:

Button button = sender as Button;
if (button != null)
{
// do your thing
}

This prevents the possibility of a casting error. BTW, why use the tag
when a button has so many other identifying properties?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Frank Oquendo said:
Nothing. However, as an alternative you might consider this:

Button button = sender as Button;
if (button != null)
{
// do your thing
}

This prevents the possibility of a casting error.

On the other hand, if the ProcessClick handler is wired up to anything
other than a button click, I think I'd want to know ASAP, and an
exception is fine here for something as catastrophic as that, IMO.
Given that handlers have to be specifically wired to events, it seems
very unlikely to me that you'd make the mistake and not notice it -
unless you deliberately made the code ignore it, as your code above
does. I suppose you could then have an:

else
{
// Log something
}

bit, but then why not just use the exception handling to start with?
 
Jon said:
bit, but then why not just use the exception handling to start with?

Who says there's going to be an exception? It's not uncommon to use a
single method to handle multiple events even from sources of differing
types. Obviously, the code I mentioned is intended for just such a
scenario.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Frank Oquendo said:
Who says there's going to be an exception?

There will be if you try to cast something to Button when it isn't one.
It's not uncommon to use a
single method to handle multiple events even from sources of differing
types. Obviously, the code I mentioned is intended for just such a
scenario.

Well, I'm afraid I didn't think that was very clear. Given the code
given, it seems reasonable to suppose that the OP *does* only intend
the method to handle button clicks. Changing the code the way you
suggested would then hide any error made in hooking up events. (ie if
you accidentally hooked the method up to an event for a non-button, you
wouldn't notice.)
 
Jon said:
There will be if you try to cast something to Button when it isn't
one.

Not when using the as operator.
Well, I'm afraid I didn't think that was very clear. Given the code
given, it seems reasonable to suppose that the OP *does* only intend
the method to handle button clicks.

Oh c'mon, John. You're a smart fellow. Why test to see if something's a
button unless it's possible that it might not be a button at all?
Changing the code the way you
suggested would then hide any error made in hooking up events. (ie if
you accidentally hooked the method up to an event for a non-button,
you wouldn't notice.)

Anyone who can make that kind of error needs a different level of help.
If they aren't asking for it, I'm not giving it. There's no need to
assume everyone is that inexperienced.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Frank Oquendo said:
Not when using the as operator.

Exactly. My point is that an exception here is, IMO, preferrable to
ignoring the problem.
Oh c'mon, John. You're a smart fellow. Why test to see if something's a
button unless it's possible that it might not be a button at all?

Because someone on the newsgroup suggested it, perhaps? It's amazing
the code people will use from newsgroups assuming it's relevant -
understandably, if it was presented as part of an answer to their
question.
Anyone who can make that kind of error needs a different level of help.
If they aren't asking for it, I'm not giving it. There's no need to
assume everyone is that inexperienced.

But you were giving a suggestion for a situation which I suspect isn't
appropriate. Why not at least include that the code should only be used
when the handler is hooked up to events which may not come from a
Button, and suggest that in that case it might be better to use
separate methods in the first place?
 
Back
Top