Handling the Red X button

[Peter Duniho]

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]

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]

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]

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.