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

[DrBonzo]

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 . . .

[Kevin Spencer]

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.

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .

[Alan Pretre]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

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.

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

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

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]
- mv*@spam.guard.caspershouse.com

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

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.

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .

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

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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .

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

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).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Alan Pretre" <no@spam> wrote in message
news:uD***************@TK2MSFTNGP09.phx.gbl...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

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.

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

[DrBonzo]

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 [.NET/C# MVP]" wrote:

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]
- mv*@spam.guard.caspershouse.com

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

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.

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .

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

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]
- mv*@spam.guard.caspershouse.com

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C8**********************************@microsof t.com...

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 [.NET/C# MVP]" wrote:

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]
- mv*@spam.guard.caspershouse.com

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

> 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.
>
> "DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
> news:C9**********************************@microsof t.com...
>> 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 . . .
>>
>
>

[Stoitcho Goutsev \(100\)]

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.
--

Stoitcho Goutsev (100)

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .

[Kevin Spencer]

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 [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eD**************@TK2MSFTNGP12.phx.gbl...

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]
- mv*@spam.guard.caspershouse.com

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP10.phx.gbl...

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.

"DrBonzo" <Dr*****@discussions.microsoft.com> wrote in message
news:C9**********************************@microsof t.com...

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 . . .