MDI child can't close itself

[Luis Alonso Ramos]

Hello, I'm trying to close a MDI child (by calling this.Close()) is trying in the Validated event handler for one of its controls, but it refuses to close. I've checked the OnClosing handler, and when called, e.Cancel is always true. I tried setting it to false, but then I get a NullReferenceException (not in my code, my debugger just pops up pointing at the last line of code in my Main). I could just hide it, but I would like it to be closed later, so it's not taking up memory unnecessarily. It seems that when I try to close it, it's in some process that has to finish, and that's the reason of the NullReferenceException. Could anyone shed some light? -- LuisR

---

Luis Alonso Ramos Intelectix - Chihuahua, Mexico Not much here: My CP Blog!

[Snowblind37]

A few things come to mind........ -What other signal flow might be trying to run? I would find this out before anything. Do you have an infinate loop going on somewhere? A reference to a method that is waiting for information? - The NullReferenceException is likely because it hasn't reached the OnClosing handler - Does the code even reach your this.Close(). Try printing out an "I'm here" before the Close and see if it is even getting that far - Not a bad idea to print out statements all the way through the flow and see where it crashes Hope that helps CodeBlind37

[Luis Alonso Ramos]

I've solved it. I already had a timer firing every 1/4 of a second, so I just set a flag mustClose to true, and in the timer the form closes itself. And it works fine. But I still have the doubt on why it didn't work. Snowblind37 wrote: What other signal flow might be trying to run? I would find this out before anything. Do you have an infinate loop going on somewhere? A reference to a method that is waiting for information? No. Nothing else. Basically on the Validated event, if it finds a duplicate asks on how to proceed (in a modal form) and if user chooses to work on the duplicate, Close() is called before returning from the event handler. Snowblind37 wrote: The NullReferenceException is likely because it hasn't reached the OnClosing handler It's after the OnClosing. I've verified it in the debugger, and the exception only happens if I set e.Cancel to false in the OnClosing handler (which misteriously is set to true.) Snowblind37 wrote: Does the code even reach your this.Close(). Yes, and from there it goes to the OnClosing handler, with e.Cancel set to true (it's not a base class where a derived class could set it before.) Snowblind37 wrote: Not a bad idea to print out statements all the way through the flow and see where it crashes I've stepped through all my code in the debugger. The crash is only when I try to set e.Cancel = false in the OnClosing handler, and it occurs after my handler returns, somewhere in the middle of the framework code. When I have some time, I'll try to reproduce it in a simpler program. Thanks for your comments! -- LuisR

---

Luis Alonso Ramos Intelectix - Chihuahua, Mexico Not much here: My CP Blog!

[Snowblind37]

Excellent!!! I'm glad to hear that you got it going. As to why this may have been happening? Your timer was probably using most of the processor time as well as being the focus of your program running time. Setting that flag was a way of making your program do something else. I suggest that you create a new thread for your timer and make sure it sleeps, then awakes at certain intervals. Code On and Good Luck!!! CodeBlind