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]

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]

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]

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]

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]

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]

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]

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]

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.

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]

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.

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]

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]

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

[...] 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?

 

[Peter Duniho]

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

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.

 

[Peter Duniho]

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

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.

 

[Peter Duniho]

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

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]

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.