DragDrop event vs. OnDragDrop(.) - what's the diff?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there any effective difference between doing something in the DragDrop
event handler and doing it in the OnDragDrop(.) method of a control? I'm
coming from a MFC background and am having a hard time comprehending the
difference.

Thanks for your explanations . . .
 
The OnDragDrop method is, in essence, a stubbed out event handler delegate
for the DragDrop event. It does nothing, unless you override it. It's there
for your convenience. If you create your own Delegate to handle the event,
you are essentially creating the same thing.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
 
Kevin Spencer said:
The OnDragDrop method is, in essence, a stubbed out event handler delegate
for the DragDrop event. It does nothing, unless you override it. It's
there for your convenience. If you create your own Delegate to handle the
event, you are essentially creating the same thing.
Click to expand...

Why does the VS WinForms Designer create a new delegate/event handler for
you instead of overriding these virtual methods? (Like when we double click
on a form to get a Form_Load handler).

-- Alan
 
Actually, this is incorrect.

The On* methods on the Control class are what are actually called when
the event is fired. If you do not call the base class implementation,
typically, the events will not get fired as well.

Overriding the method allows you to determine when the events are fired,
and perform any pre and/or post-processing that might be necessary.
 
DrBonzo,

The difference is that OnDragDrop is actually the method that is called
to fire any event handlers which are attached to the control instance. If
you override OnDragDrop, and do not call the base class implementation, the
events will not be fired.

Generally speaking, if you are deriving from the class, it would be more
efficient to create an implementation for the method, making sure to call
the base class implementation.

However, there is no designer support for this beyond what it offers for
regular overridden methods.

Hope this helps.
 
Alan,

The reason is most likely because there is nothing in the metadata
indicating that there is an association between these events and the methods
that fire them.

It would be as simple as attaching an attribute to a method (saying, in
essence, "hey, I fire event X!"), but it's up to MS to implement it.

Also, it's easier to create an empty method stub than it is to create
one with code in it (although not that hard, since it's just a call to the
base).
 
I think I've read in the dox that the On* methods 'fire the event' - does
this mean that the base implementations are what actually call all the
associated event handlers?

Nicholas Paldino said:
Actually, this is incorrect.

The On* methods on the Control class are what are actually called when
the event is fired. If you do not call the base class implementation,
typically, the events will not get fired as well.

Overriding the method allows you to determine when the events are fired,
and perform any pre and/or post-processing that might be necessary.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin Spencer said:
The OnDragDrop method is, in essence, a stubbed out event handler delegate
for the DragDrop event. It does nothing, unless you override it. It's
there for your convenience. If you create your own Delegate to handle the
event, you are essentially creating the same thing.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
Click to expand...
Click to expand...
 
DrBonzo,

In the case where you are extending Control, yes, it is. It's not a
hard and fast rule, but you can see it in MS's implementation of classes all
over the place.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

DrBonzo said:
I think I've read in the dox that the On* methods 'fire the event' - does
this mean that the base implementations are what actually call all the
associated event handlers?

Nicholas Paldino said:
Actually, this is incorrect.

The On* methods on the Control class are what are actually called
when
the event is fired. If you do not call the base class implementation,
typically, the events will not get fired as well.

Overriding the method allows you to determine when the events are
fired,
and perform any pre and/or post-processing that might be necessary.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin Spencer said:
The OnDragDrop method is, in essence, a stubbed out event handler
delegate
for the DragDrop event. It does nothing, unless you override it. It's
there for your convenience. If you create your own Delegate to handle
the
event, you are essentially creating the same thing.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

Is there any effective difference between doing something in the
DragDrop
event handler and doing it in the OnDragDrop(.) method of a control?
I'm
coming from a MFC background and am having a hard time comprehending
the
difference.

Thanks for your explanations . . .
Click to expand...
Click to expand...
Click to expand...
 
DrBonzo,

As MS says in their docs overriding On* method is preferable way of handling
the events in a case of ingeritanse.

Usually you hook events when you don't derive a new class in this case
overriding is not an option.

Hooking events is also a way to provide more than one hendler for an event.
 
Hi Nicholas,

Yes, that is correct. I wouldn't say that my answer was incorrect. It was a
simplification (note the use of the word "essentially"). However, because of
what you mentioned, using the On* methods is more efficient than wiring up
your own event handlers.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

Nicholas Paldino said:
Actually, this is incorrect.

The On* methods on the Control class are what are actually called when
the event is fired. If you do not call the base class implementation,
typically, the events will not get fired as well.

Overriding the method allows you to determine when the events are
fired, and perform any pre and/or post-processing that might be necessary.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin Spencer said:
The OnDragDrop method is, in essence, a stubbed out event handler
delegate for the DragDrop event. It does nothing, unless you override it.
It's there for your convenience. If you create your own Delegate to
handle the event, you are essentially creating the same thing.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
Click to expand...
Click to expand...
 
Back
Top