简体   繁体   中英

Is the framework setting e.Cancel to true?

I'm writing a Windows Forms app (2.0 framework), and I'm running into a strange bug.

In my form, when a particular exception is thrown, I have a catch block that is supposed to log the error, inform the user with a dialog box, and then close the form by calling this.Close(). The first two steps work fine, but this.Close() doesn't do anything. My first thought was that I must have an event handler that is setting e.Cancel to true, but after thoroughly checking the code, I couldn't find one. Also, I had not overridden the form's OnCancel method.

During the process of trying to track down the bug, I wrote an override for the form's OnCancel method and set a break point in it. At the beginning of OnCancel, e.Cancel is already set to true. If my understanding is correct, the override should run before any event handlers, so that seems to rule out the possibility of this problem being caused by an event handler that I missed somehow.

In my OnClosing override method, if I set e.Cancel to false, the form closes fine, and my program works as I intended it to, but I don't want to fix it that way. There is obviously some code that is creating an unexpected side-effect, and I want to understand what's going on rather than resorting to "digital duct tape."

It seems like the framework itself is canceling my form closing. Are there any situations where the framework would do that?

Thanks.

edit...

I created a small test project and was able to recreate the error on a much simpler form.

If you would like the recreate the situation so that you can see what I mean, try this... Create a form and add a textbox (I assume other controls would work too). Have your form handle the text box's Validated event, and within the handler call this.Close. Now override Form.OnClosing() and set a breakpoint in it.

Now run the program, type some text, and tab out of the textbox so it validates (I guess you'll want to add a button or something so that you have some other control to tab to.)

At the beginning of OnClosing, e.Cancel will be automatically set to true This is what I'm trying to figure out. Why is that happening?

I have the exact same scenario in the Framework 2.0. If a certain set of events occur, then the following code will stop at a break point on 3rd line of this sub every time thereafter regardless of what else happens in the app.

This seems to happen after we disable all of the controls on a form and then enable all of those same controls and then close that form (we are locking that form down as another process changes some related data).

If this is the lowest method in the system for the application form closing event then what else can be setting e.Cancel to true except the framework?

Protected Overrides Sub OnFormClosing(e As System.Windows.Forms.FormClosingEventArgs)
  If e.Cancel Then
    e.Cancel = False
  End If
  MyBase.OnFormClosing(e)
End Sub

I'm not sure if you are asking us to guess if your code is correct or what exactly. I can tell you that I've never seen this problem.

However, it is painfully easy to determine if some event handler is canceling: just use the debugger. Step through the code and see what happens.

Given the tiny amount of details you've provided here, I think your focus should be on figuring out what is happening.

You question is quite unclear. You refer to a method, OnCancel , however no such method exists in the Form class. You are using .NET 2.0 according to the first sentence in your question, however you are overriding Form.OnClosing . Note that this method is deprecated as of version 2.0 of the framework. You should be using Form.OnFormClosing instead, new as of 2.0. Please try overriding that method instead and see if you observe the same issue. I have certainly never seen such a thing from OnFormClosing .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM