Handling the Red X button

[melon]

Hello,

Is there anyway to force the application to handle the Red X button
differently? I cannot use a generic Closing event as it will prevent
the system to shut down properly. I hope that, when clicking on the
red X button it will only minimize the window, or just hide it.

[Andy]

On May 7, 4:50 pm, melon <[e-mail]:

Hello,

Is there anyway to force the application to handle the Red X button
differently? I cannot use a generic Closing event as it will prevent
the system to shut down properly. I hope that, when clicking on the
red X button it will only minimize the window, or just hide it.

Handle the closing event, and check the parameter that tells you why
the application is shutting down. You can determine if its because
the user or because the system is shutting down.

HTH
Andy

[melon]

On May 7, 4:52 pm, Andy <[e-mail]:

On May 7, 4:50 pm, melon <[e-mail]:

Hello,

Is there anyway to force the application to handle the Red X button
differently? I cannot use a generic Closing event as it will prevent
the system to shut down properly. I hope that, when clicking on the
red X button it will only minimize the window, or just hide it.

Handle the closing event, and check the parameter that tells you why
the application is shutting down. You can determine if its because
the user or because the system is shutting down.

HTH
Andy

I am fairly new to C#. Would you mind to show me how?

Thanks.

[melon]

On May 7, 4:52 pm, Andy <[e-mail]:

On May 7, 4:50 pm, melon <[e-mail]:

Hello,

Is there anyway to force the application to handle the Red X button
differently? I cannot use a generic Closing event as it will prevent
the system to shut down properly. I hope that, when clicking on the
red X button it will only minimize the window, or just hide it.

Handle the closing event, and check the parameter that tells you why
the application is shutting down. You can determine if its because
the user or because the system is shutting down.

HTH
Andy

Would you mind to show me how? I am fairly new to C#.

Thanks.

P.S. This may be a double post.

[Peter Duniho]

On Mon, 07 May 2007 14:25:50 -0700, melon <el*****@gmail.comwrote:

I am fairly new to C#. Would you mind to show me how?

For example, in your form's class:

protected override void OnFormClosing(object sender,
FormClosingEventArgs e)
{
switch (e.CloseReason)
{
case CloseReason.UserClosing:
// User has explicitly closed the form
break;
case CloseReason.WindowsShutDown:
// Windows is shutting down
break;
default:
// Something else happened
break;
}

base.OnFormClosing(sender, e);
}

Note that there are other values in the CloseReason enumeration. If you
are interested in handling additional cases or combining them with the
example cases above, you'd just add them to the switch() statement.

(My apologies if there's something not quite right about the syntax
above...I didn't actually try to compile it. But it should give you the
general idea).

Pete

[Andy]

On May 7, 7:23 pm, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 07 May 2007 14:25:50 -0700, melon <[e-mail]:

I am fairly new to C#. Would you mind to show me how?

For example, in your form's class:

protected override void OnFormClosing(object sender,
FormClosingEventArgs e)
{
switch (e.CloseReason)
{
case CloseReason.UserClosing:
// User has explicitly closed the form
break;
case CloseReason.WindowsShutDown:
// Windows is shutting down
break;
default:
// Something else happened
break;
}

base.OnFormClosing(sender, e);
}

Note that there are other values in the CloseReason enumeration. If you
are interested in handling additional cases or combining them with the
example cases above, you'd just add them to the switch() statement.

(My apologies if there's something not quite right about the syntax
above...I didn't actually try to compile it. But it should give you the
general idea).

Pete

There's no need to override the method; typically you'd simply listen
for the FormClosing event. The advantage is that you can do that in
the designer, and someone using the designer can see all the events
handled by the form.

[Peter Duniho]

On Tue, 08 May 2007 05:53:26 -0700, Andy <an***@med-associates.comwrote:

There's no need to override the method; typically you'd simply listen
for the FormClosing event. The advantage is that you can do that in
the designer, and someone using the designer can see all the events
handled by the form.

And the disadvantage is that if you are trying to reuse the class and
someone wants to add a FormClosing event handler for some other purpose,
in the designer they only have the choice to remove your reference for the
handling for this purpose. If you instead add your event handler
programmatically, well then you've just lost the advantage you're claiming.

I've just been through this, and based on the feedback from others as well
as my own analysis, I'm convinced that if the behavior you're trying to
hook up should be an integral part of your class, then you *should*
override the method rather than using an event handler. It's more
efficient and ensures that the behavior you've implemented cannot be
removed (accidently or on purpose) from your class.

Pete

[Andy]

On May 8, 12:49 pm, "Peter Duniho" <[e-mail]>
wrote:

And the disadvantage is that if you are trying to reuse the class and
someone wants to add a FormClosing event handler for some other purpose,
in the designer they only have the choice to remove your reference for the
handling for this purpose. If you instead add your event handler
programmatically, well then you've just lost the advantage you're claiming.

While I agree with your point, in my experiece you typically don't
create a Form expecting others to inherit from that form.

I've just been through this, and based on the feedback from others as well
as my own analysis, I'm convinced that if the behavior you're trying to
hook up should be an integral part of your class, then you *should*
override the method rather than using an event handler.

Again, in general this is true. But my experience creating forms is
that you don't usually inherit from anything but Form, and so this
issue is pretty uncommon. Given the OP, I don't forsee the need for
creating more base forms at this time.

It's more
efficient and ensures that the behavior you've implemented cannot be
removed (accidently or on purpose) from your class.

That's only the case if you're going to seal the class. Otherwise,
someone could purposefully derive the class and override the method in
question without calling the base implementation of the method. Also
in .Net 2, delegates are much quicker now, almost on part with direct
method calls. So I imagine performance difference between using
events vs. overriding a virtual method (which has its own perf. hit)
is moot.

[Peter Duniho]

On Wed, 09 May 2007 09:00:28 -0700, Andy <an***@med-associates.comwrote:

While I agree with your point, in my experiece you typically don't
create a Form expecting others to inherit from that form.

I don't think that's the issue. The point is even without inheriting, the
form may be reused, and someone (you, even) may wind up wanting a
different or new FormClosing event handler for something that is less
inherently related to the behavior of the form.

Again, in general this is true. But my experience creating forms is
that you don't usually inherit from anything but Form, and so this
issue is pretty uncommon. Given the OP, I don't forsee the need for
creating more base forms at this time.

You've already created a base form. When you add a form to a project, you
get a new class, derived from Form. Overriding any particular method in
the base Form class is trivial.

>It's more
efficient and ensures that the behavior you've implemented cannot be
removed (accidently or on purpose) from your class.

That's only the case if you're going to seal the class.

Actually, it's *always* more efficient, whether or not you seal the class.

Otherwise,
someone could purposefully derive the class and override the method in
question without calling the base implementation of the method.

But they would do so with the more explicit knowledge that they are
overriding whatever behavior was already there.

Also
in .Net 2, delegates are much quicker now, almost on part with direct
method calls. So I imagine performance difference between using
events vs. overriding a virtual method (which has its own perf. hit)
is moot.

Performance differences are almost always moot. But they exist,
nevertheless. Execution of a delegate attached to an event is never going
to be as efficient as executing a virtual method. It has all the aspects
of the virtual method, plus additional work.

Pete

[Andy]

On May 9, 12:43 pm, "Peter Duniho" <[e-mail]>
wrote:

I don't think that's the issue. The point is even without inheriting, the
form may be reused, and someone (you, even) may wind up wanting a
different or new FormClosing event handler for something that is less
inherently related to the behavior of the form.

I'd think then you'd simply add it to the event handler. If its
another class interested in the FormClosing event, you can't wire
things up in the designer, and you can't affect any other event
handlers currently wired when you hook into the event. In my original
suggestion, I had the form listening for its own FormClosing event.
Sorry if that wasn't clear.

You've already created a base form. When you add a form to a project, you
get a new class, derived from Form. Overriding any particular method in
the base Form class is trivial.

My point was that you rarely ever inherit from a subclass of Form
you've created. Hooking up a private event handler to handle the
forms own closing event is equally as trivial, and the event is
visible from within the designer window as well.

It's more
efficient and ensures that the behavior you've implemented cannot be
removed (accidently or on purpose) from your class.

That's only the case if you're going to seal the class.

Actually, it's *always* more efficient, whether or not you seal the class.

I addressed performance in my previous post; overriding a method
incurs some overhead too, due to lookups need in vtables. So
efficiency isn't really a concern.

But they would do so with the more explicit knowledge that they are
overriding whatever behavior was already there.

But your point of overriding to *ensure* that the behavior cannot be
changed is not valid unless you seal the class, which is what I was
addressing. You'd have to explicity remove the event handler from the
base as well, you can't accidently remove that behavior, assuming the
event handler is a private method which is standard practice.

Performance differences are almost always moot. But they exist,
nevertheless. Execution of a delegate attached to an event is never going
to be as efficient as executing a virtual method. It has all the aspects
of the virtual method, plus additional work.

If the differences are moot, then it should not be a factor in using
an event handler or an override.

Also, do you have any evidence to support your theory that delegates
work the same as a virtual method, but have additional work instead?
You assert that as fact, yet I haven't seen any documentation that
suggests that's the case.

[Peter Duniho]

On Wed, 09 May 2007 12:13:22 -0700, Andy <an***@med-associates.comwrote:

If the differences are moot, then it should not be a factor in using
an event handler or an override.

The best you've come up with as an argument in favor of using an event
handler is aesthetic in nature. If we're talking aesthetics, then a
performance difference -- even if moot -- is fair game, as I find things
that perform better to be aesthetically superior.

Also, do you have any evidence to support your theory that delegates
work the same as a virtual method, but have additional work instead?
You assert that as fact, yet I haven't seen any documentation that
suggests that's the case.

They are both essentially function pointers. However, a virtual method is
always just a single function pointer, and I doubt any type-checking has
to be done at run-time, since all the relevant information is available
for checking at compile time. On the other hand, an event is a list of
delegates, so at a minimum that list has to be enumerated. Even if
there's only one element, that's more work than just dealing with a single
function pointer. Furthermore, delegates are type-safe and not checkable
at compile time, so there's extra work to deal with that.

Do I have documentation that describes all of the above? No. And yes,
it's entirely possible that between the C# compiler and the .NET Framework
implementations, those responsible for the implementations screwed up and
caused event handling to be more costly than using virtual methods. But I
think the likelyhood of that is _extremely_ low. The basic mechanics
dictate that event handling is more costly than dealing with virtual
methods, and the implementations would have to be pretty poor for them to
not follow that conclusion.

That said, I find this argument to be just as silly as all the other silly
arguments that show up here, and I'm embarassed to have been a part of
it. The fact is, you can do it either way, and there is no very strong
argument in favor of either method. If you prefer to go against the MSDN
documenation recommendation to override the OnFormClosing method in the
Form class, it's not really going to hurt much to do that. Just don't go
around pretending that there's a strong argument in favor of *not*
overriding.

Pete

[Peter Duniho]

On Wed, 09 May 2007 12:59:31 -0700, Peter Duniho
<Np*********@nnowslpianmk.comwrote:

[...] And yes, it's entirely possible that between the C# compiler and
the .NET Framework implementations, those responsible for the
implementations screwed up and caused event handling to be more costly
than using virtual methods.

And, obviously, I meant to write exactly the opposite ("...screwed up and
caused virtual methods to be more costly than using event handling.").
That should be readily apparent, but my apologies to anyone who was
confused by the statement.

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nnowslpianmk.comwrote:

On Wed, 09 May 2007 12:59:31 -0700, Peter Duniho
<Np*********@nnowslpianmk.comwrote:

[...] And yes, it's entirely possible that between the C# compiler and
the .NET Framework implementations, those responsible for the
implementations screwed up and caused event handling to be more costly
than using virtual methods.

And, obviously, I meant to write exactly the opposite ("...screwed up and
caused virtual methods to be more costly than using event handling.").
That should be readily apparent, but my apologies to anyone who was
confused by the statement.

I did have to read it a couple of times and decide it was a mistake
given the rest of the post. Any chance you could clear up something
else? This bit:

<quote>
Furthermore, delegates are type-safe and not checkable
at compile time, so there's extra work to deal with that.
</quote>

Delegates *are* checkable at compile-time - just try to provide the
wrong kind of delegate!

Moreover, even though they no doubt also require runtime checking, I'd
hope that only needs to be done at the point of event subscription,
rather than when actually *running* the delegate.

Perhaps you meant something other than how I understood you?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Wed, 09 May 2007 13:16:42 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

[...]
Delegates *are* checkable at compile-time - just try to provide the
wrong kind of delegate!

Moreover, even though they no doubt also require runtime checking, I'd
hope that only needs to be done at the point of event subscription,
rather than when actually *running* the delegate.

Perhaps you meant something other than how I understood you?

I'm not sure. Let's see. :)

What I'm talking about is the work necessary to handle casting a delegate.

For example:

public delegate void MyDelegate();
public delegate void MyOtherDelegate(int i);

public void MyMethod()
{
}

public void OtherMethod()
{
Delegate del1 = new MyDelegate(MyMethod);
MyDelegate del2 = (MyDelegate)del1;
MyOtherDelegate del3 = (MyOtherDelegate)del1;
}

You get a run-time InvalidCastException when the third line of
OtherMethod() is executed. This means there is run-time type checking for
delegates.

Now, it may be when you add a delegate to an event, as long as no casting
is done the type-checking is also not done. But the *ability* to do the
type-checking still exists, and that implies more overhead for the
delegate instance. Even if the type information isn't used, it's carried
around with the delegate.

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nnowslpianmk.comwrote:

Perhaps you meant something other than how I understood you?

I'm not sure. Let's see. :)

What I'm talking about is the work necessary to handle casting a delegate.

For example:

public delegate void MyDelegate();
public delegate void MyOtherDelegate(int i);

public void MyMethod()
{
}

public void OtherMethod()
{
Delegate del1 = new MyDelegate(MyMethod);
MyDelegate del2 = (MyDelegate)del1;
MyOtherDelegate del3 = (MyOtherDelegate)del1;
}

You get a run-time InvalidCastException when the third line of
OtherMethod() is executed. This means there is run-time type checking for
delegates.

For assignment/addition etc, yes. Not for execution - because the type
checking has already been done.

Now, it may be when you add a delegate to an event, as long as no casting
is done the type-checking is also not done.

The type checking is done at compile-time, unless you cast - you can
only subscribe to an event with the appropriate type of delegate.

But the *ability* to do the type-checking still exists, and that
implies more overhead for the delegate instance. Even if the type
information isn't used, it's carried around with the delegate.

Absolutely. My point is that there doesn't need to be a type check done
every time you *execute* a delegate, precisely because you already know
it's the right kind of delegate.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Wed, 09 May 2007 13:53:50 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

[...]
Absolutely. My point is that there doesn't need to be a type check done
every time you *execute* a delegate, precisely because you already know
it's the right kind of delegate.

Oh, I agree with that. Frankly, it's my opinion that there is basically
no practical difference between delegates and virtual functions from a
performance perspective. However, if one is going to assert that there
*is* a difference (as Andy did), it's my opinion that clearly the virtual
function is going to be less expensive than executing a delegate from an
event.

I'm just trying to point out what extra overhead does exist, as irrelevant
as it may be. :)

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nnowslpianmk.comwrote:

<snip>

I'm just trying to point out what extra overhead does exist, as irrelevant
as it may be. :)

Fair enough :)

Without wanting to get involved in the debate particularly, I'd just
like to point out the major benefits of using events over inheritance:

1) You don't need to create a new type solely for the purpose of
changing a few event-based aspects of behaviour

2) You can affect the behaviour of *any* instance of the relevant
control, not just instances of your own custom types derived from it

3) Multiple interested parties can easily add their own behaviour
without being aware of each other

I don't know whether any of this is new to you (I doubt it) but I
thought I'd just my 2p.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Wed, 09 May 2007 15:51:52 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

[...
I don't know whether any of this is new to you (I doubt it) but I
thought I'd just my 2p.

Those are all good points.

My response was in the context of a situation in which the object is
already sub-classed, adding a behavior that doesn't seem to me to be in
need of encapsulating for reuse. But given the somewhat tangential
discussion about events vs inheritance, your points are probably a useful
supplement to anyone following the discussion.

Thanks,
Pete

[Andy]

On May 9, 3:59 pm, "Peter Duniho" <[e-mail]>
wrote:

The best you've come up with as an argument in favor of using an event
handler is aesthetic in nature. If we're talking aesthetics, then a
performance difference -- even if moot -- is fair game, as I find things
that perform better to be aesthetically superior.

The discoverablity of code is not aesthetic in nature. When you're
designing forms, you typically spend a good deal of time in the
designer. Its also very easy to find all events for a form which are
handled by looking in just one place. Overrides on the otherhand are
not as easily discoverable; you need to open the code window, and
scroll through the members dropdown to see if an override exists or
not. With all the other members in that same list, it can be easy to
miss what you're looking for. I would also argue that most code uses
the event handler method.

All of those factors above lead to easier maintenance.

They are both essentially function pointers. However, a virtual method is
always just a single function pointer, and I doubt any type-checking has
to be done at run-time, since all the relevant information is available
for checking at compile time. On the other hand, an event is a list of
delegates, so at a minimum that list has to be enumerated. Even if
there's only one element, that's more work than just dealing with a single
function pointer. Furthermore, delegates are type-safe and not checkable
at compile time, so there's extra work to deal with that.

I hardly thing a single addition is going to make any difference at
all in performance. Its so insigificant that if that performace 'hit'
is important, you probably shouldn't even be using C# to code your
application. At that point, you need C/C++ or assembly. I'm not sure
if you've made a mistake on your last point, but to be clear,
delegates ARE type safe and using the wrong one will cause a
compilation error.

Do I have documentation that describes all of the above? No. And yes,
it's entirely possible that between the C# compiler and the .NET Framework
implementations, those responsible for the implementations screwed up and
caused event handling to be more costly than using virtual methods. But I
think the likelyhood of that is _extremely_ low. The basic mechanics
dictate that event handling is more costly than dealing with virtual
methods, and the implementations would have to be pretty poor for them to
not follow that conclusion.

In other words, you have no proof, but run off and proclaim this to be
truth. I suggest you don't make statements such as there. It could
be that delegates are faster due to some optimization that's not
possible with subclassing. You seem to be thinking that .Net is C++,
its not. Its entirely possible that due to JITting deleagates are
faster.

That said, I find this argument to be just as silly as all the other silly
arguments that show up here, and I'm embarassed to have been a part of
it. The fact is, you can do it either way, and there is no very strong
argument in favor of either method. If you prefer to go against the MSDN
documenation recommendation to override the OnFormClosing method in the
Form class, it's not really going to hurt much to do that. Just don't go
around pretending that there's a strong argument in favor of *not*
overriding.

You were the one that was so adament that 'overriding is the best
way.' The documentation fails to mention any reasoning as to why its
the prefered method. Also, VS itself seems to encourage using the
event handler. At any rate, if you really thought this was a silly
discussion, I don't see why you bothered posting anything in response
to my initial post.

[Andy]

On May 9, 6:45 pm, "Peter Duniho" <[e-mail]>
wrote:

Oh, I agree with that. Frankly, it's my opinion that there is basically
no practical difference between delegates and virtual functions from a
performance perspective. However, if one is going to assert that there
*is* a difference (as Andy did), it's my opinion that clearly the virtual
function is going to be less expensive than executing a delegate from an
event.

I never said there were performance benefits to using the event
handler method. You really need to go back and carefully read what I
posted. I said the more *standard* way was to use the event handler.
That is, 99% of the code I see uses that method, VS itself makes it
easy to use that method. My only arguement was that I believe it
makes code more maintainable, for reasons I've already listed.

[Peter Duniho]

On Thu, 10 May 2007 05:35:28 -0700, Andy <an***@med-associates.comwrote:

I never said there were performance benefits to using the event
handler method. You really need to go back and carefully read what I
posted.

I see. I misunderstood your use of the word "quicker" in a previous post.

Still...

I said the more *standard* way was to use the event handler.

Given that MSDN in each OnXXX page specifically says it is preferable to
override the event handler method than to add a delegate to the event, I
don't see how you support the claim that the latter is "standard".

Pete

[Peter Duniho]

On Thu, 10 May 2007 05:31:11 -0700, Andy <an***@med-associates.comwrote:

The discoverablity of code is not aesthetic in nature. When you're
designing forms, you typically spend a good deal of time in the
designer.

I don't. I don't know why you do, but I spend most of my time in the code
window, writing code. I spend very little time in the designer, and when
I am there I am almost always just dragging and dropping stuff, to arrange
them visually on the form.

Its also very easy to find all events for a form which are
handled by looking in just one place.

No, it's not. You cannot rely on the designer to show you all of the
handlers for events, because code anywhere else in the application could
add a delegate. The only way to know where the handlers are is to search
the source code (which will show you both the handlers added with the
designer as well as those added programmatically elsewhere).

Overrides on the otherhand are
not as easily discoverable; you need to open the code window, and
scroll through the members dropdown to see if an override exists or
not. With all the other members in that same list, it can be easy to
miss what you're looking for.

All I do is hit Ctrl-F, and then search for the name of the method I'm
looking for. No chance of me missing anything. For a partial class,
there are other easy ways to get at the method as well.

I would also argue that most code uses the event handler method.

Frankly, "most code" sucks. Prevalance is not proof of, or even
suggestive of, superiority. That's even assuming you can justify the
claim that "most code uses the event handler method", and even assuming
that claim is relevant (a lot of code may *have* to use the event handler
method due to the fact that it isn't implemented in the same class where
the overridable method exists).

All of those factors above lead to easier maintenance.

First, "easier maintenance" is in a lot of ways in the eye of the
beholder. Certainly the "factors" you bring up are wholely subjective.
But even so, "all of those factors" turn out to not be much in the way of
factors at all, as I've noted above.

[...]
You were the one that was so adament that 'overriding is the best
way.'

I challenge you to find a post from me that says "overriding is the best
way". I was simply responding to your post claiming that "There's no need
to override the method; typically you'd simply listen for the FormClosing
event", implying that my suggestion to override the method was faulty in
some way. It is you that started with the claim that your way is "best"
(though you instead use words like "typical", "preferable", "standard",
etc. they all have the same implication).

The documentation fails to mention any reasoning as to why its
the prefered method.

So, because it fails to justify its statement, the statement should just
be ignored? You're going to have to toss out a LOT of MSDN documentation
if that's the approach you want to take.

Also, VS itself seems to encourage using the event handler.

How so? In what way is VS *encouraging* use of the event handler? It
provides easy and convenient access to *both* approaches. When I override
a method in a class, I sure don't see VS popping up and saying "I
encourage you to use an event handler instead". Instead, it finishes the
declaration of the method for me, and even fills in a call to the base
class implementation.

At any rate, if you really thought this was a silly
discussion, I don't see why you bothered posting anything in response
to my initial post.

Call it "personality defect". You posted in reply to mine in a way that I
construed as being negative or dismissive of my suggestion, and I
responded to defend my original reply. If you had written instead that
your suggestion was simply an alternative, that would've been the end of
it. But you felt a need for some reason to make the implication that my
suggestion was wrong, and here we are.

Pete

[Andy]

On May 10, 1:02 pm, "Peter Duniho" <[e-mail]>
wrote:

Given that MSDN in each OnXXX page specifically says it is preferable to
override the event handler method than to add a delegate to the event, I
don't see how you support the claim that the latter is "standard".

I explained this already; by looking at the code sample, and the fact
that VS helps you write such code.

[Andy]

On May 10, 1:21 pm, "Peter Duniho" <[e-mail]>
wrote:

I don't. I don't know why you do, but I spend most of my time in the code
window, writing code. I spend very little time in the designer, and when
I am there I am almost always just dragging and dropping stuff, to arrange
them visually on the form.

I assume then you're not doing things like hooking up databinding in
the designer then, which I personally have found to be very helpful.

No, it's not. You cannot rely on the designer to show you all of the
handlers for events, because code anywhere else in the application could
add a delegate. The only way to know where the handlers are is to search
the source code (which will show you both the handlers added with the
designer as well as those added programmatically elsewhere).

That's true, other code could hook in their own listeners. But in a
scenario such as the OP's, it doesn't really matter if there are other
listeners, or they would likely not cause the form to abort closing.

All I do is hit Ctrl-F, and then search for the name of the method I'm
looking for. No chance of me missing anything. For a partial class,
there are other easy ways to get at the method as well.

A mispelling could cause you to believe that an override does not
exist.

Frankly, "most code" sucks. Prevalance is not proof of, or even
suggestive of, superiority. That's even assuming you can justify the
claim that "most code uses the event handler method", and even assuming
that claim is relevant (a lot of code may *have* to use the event handler
method due to the fact that it isn't implemented in the same class where
the overridable method exists).

Standard != superior. My point was that it seems the event handler is
the method most often seen. For controls on a form you are right,
there may not be an easier way to get the behavior you want because
you'd have a lot of control subclasses. I would image though that it
would be trivial for VS to hide the Events part of the properties
window when examining a Form or UserControl.

First, "easier maintenance" is in a lot of ways in the eye of the
beholder. Certainly the "factors" you bring up are wholely subjective.
But even so, "all of those factors" turn out to not be much in the way of
factors at all, as I've noted above.

I'm not sure. If many developers see the event handler method, and
many developers use it (as has been my experience), that's what most
developers would look for when maintaining the code. That's all.

I challenge you to find a post from me that says "overriding is the best
way". I was simply responding to your post claiming that "There's no need
to override the method; typically you'd simply listen for the FormClosing
event", implying that my suggestion to override the method was faulty in
some way. It is you that started with the claim that your way is "best"
(though you instead use words like "typical", "preferable", "standard",
etc. they all have the same implication).

Again, standard != best. Smtp is a standard. Is it the best for for
transfering emails? No, it has many flaws, but its standard.

So, because it fails to justify its statement, the statement should just
be ignored? You're going to have to toss out a LOT of MSDN documentation
if that's the approach you want to take.

When it seems that it doesn't really matter either way which you
choose then I expect some kind of reasoning. I don't recall seeing
topics (not that I've read 100% of the documentation either) where a
recommendation came out of no where and it wasn't immedately obvious
why one was 'prefered.'

How so? In what way is VS *encouraging* use of the event handler? It
provides easy and convenient access to *both* approaches. When I override
a method in a class, I sure don't see VS popping up and saying "I
encourage you to use an event handler instead". Instead, it finishes the
declaration of the method for me, and even fills in a call to the base
class implementation.

Fair enough, its probably just the way I'm using to working.
Typically, I hook up the event handlers all at the same time. So to
me it makes sense that I hook up the handlers for the form at the same
time I'm hooking up other events.

Call it "personality defect". You posted in reply to mine in a way that I
construed as being negative or dismissive of my suggestion, and I
responded to defend my original reply. If you had written instead that
your suggestion was simply an alternative, that would've been the end of
it. But you felt a need for some reason to make the implication that my
suggestion was wrong, and here we are.

Ok, understandable. The only reason though that I tried to steer the
OP in one direction was because that's what's typically seen in my
experience.