471,347 Members | 1,770 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,347 software developers and data experts.

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

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

Jan 10 '06 #1
9 2278
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 . . .

Jan 10 '06 #2
"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
Jan 10 '06 #3
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 . . .


Jan 10 '06 #4
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 . . .

Jan 10 '06 #5
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

Jan 10 '06 #6
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 . . .



Jan 10 '06 #7
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 . . .
>>
>
>


Jan 10 '06 #8
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 . . .

Jan 10 '06 #9
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 . . .



Jan 10 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Dave Wurtz | last post: by
9 posts views Thread by Marcelo Cabrera | last post: by
9 posts views Thread by jeff | last post: by
19 posts views Thread by Daniela Roman | last post: by
11 posts views Thread by antonyliu2002 | last post: by
7 posts views Thread by Ben | last post: by
reply views Thread by Ronak mishra | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.