views:

4466

answers:

6

I've kind of backed myself into a corner here.

I have a series of UserControls that inherit from a parent, which contains a couple of methods and events to simplify things so I don't have to write lines and lines of near-identical code. As you do. The parent contains no other controls.

What I want to do is just have one event handler, in the parent UserControl, which goes and does stuff that only the parent control can do (that is, conditionally calling an event, as the event's defined in the parent). I'd then hook up this event handler to all my input boxes in my child controls, and the child controls would sort out the task of parsing the input and telling the parent control whether to throw that event. Nice and clean, no repetitive, copy-paste code (which for me always results in a bug).

Here's my question. Visual Studio thinks I'm being too clever by half, and warns me that "the method 'CheckReadiness' [the event handler in the parent] cannot be the method for an event because a class this class derives from already defines the method." Yes, Visual Studio, that's the point. I want to have an event handler that only handles events thrown by child classes, and its only job is to enable me to hook up the children without having to write a single line of code. I don't need those extra handlers - all the functionality I need is naturally called as the children process the user input.

I'm not sure why Visual Studio has started complaining about this now (as it let me do it before), and I'm not sure how to make it go away. Preferably, I'd like to do it without having to define a method that just calls CheckReadiness. What's causing this warning, what's causing it to come up now when it didn't an hour ago, and how can I make it go away without resorting to making little handlers in all the child classes?

A: 

If your event is already defined in your parent class, you do not need to rewire it again in your child class. That will cause the event to fire twice.

Do verify if this is what is happening. HTH :)

Jon Limjap
A: 

This article on MSDN should be a good starting points: Overriding Event Handlers with Visual Basic .NET. Take a look at the How the Handles Clause Can Cause Problems in the Derived Class section.

Dario Solera
A: 

Why not declare the method as virtual in the parent class and then you can override it in the derived classes to add extra functionality?

Phil Wright
So I don't have to write handlers for each class that are identical. These are pretty small controls. There's not much extra functionality I need.
Merus
+4  A: 

Declare the parent method virtual, override it in the child classes and call

base.checkReadyness(sender, e);

(or derevation thereof) from within the child class. This allows for future design evolution say if you want to do some specific error checking code before calling the parent event handler. You might not need to write millions of event handlers like this for each control, you could just write one, hook all the controls to this event handler which in turn calls the parent's event handler.

One thing that I have noted is that if all this code is being placed within a dll, then you might experience a performance hit trying to call an event handler from within a dll.

TK
That'd solve the problem, but I was hoping to avoid having essentially empty error handlers, hence my question.
Merus
I don't think that they're redundant though, you are keeping the controls and the event handlers essentially co-located in the same place. This could (depending on the code layout) lead to better readability of the code etc. Its just that all the work is done elsewhere!
TK
Seems the right thing to do... it seems only to be a designer problem though...
BeowulfOF
A: 

Forget that it's an event handler and just do proper regular method override in child class.

ima
+1  A: 

I've just come across this one as well, I agree that it feels like you're doing everything correctly. Declaring the method virtual is a work-around at best, not a solution.

What is being done is valid - a control which only exists in the derived class, and the derived class is attaching an event handler to one of that control's events. The fact that the method which is handling the event is defined in the base class is neither here nor there, it is available at the point of binding to the event. The event isn't being attached to twice or anything silly like that, it's simply a matter of where the method which handles the event is defined.

Most definitely it is not a virtual method - I don't want the method to be overridable by a derived class. Very frustrating, and in my opinion, a bug in dev-studio.

MrCranky