Develop Reference

How does x_FormClosing work?

I am developing Windows Form application and I wanted to execute some code when the user closes the window. Most people did it by using
This didn't work, and I've seen that you have to add events like this
Then, it actually worked, the code executes when I close the window but the next problem was there. The application didn't exit at closing the window. So I tried to add "Application.Exit();"
Now, it seemed to work. But it prints out the debugging message "Closed" two times. So it seems like even if the form is closed, Application.Exit() triggers the x_FormClosing method a second time ... any ideas?

The Form hasn't fully closed yet and Application.Exit is going to call .Close on all open forms. Closing allows for the operation to be cancelled.
An application, by default will exit after all forms are closed. If you want this form to be a "master", consider putting it in the Closed event.

Windows Form 2 minimizes on the closing of Form 1

Strange problem here. I have a Login form, which opens a Registration form when the user clicks a button:
Register registration = new Register();
registration.Show();
At which point, this second form opens in front of the Login form - both windows are open and not minimized, which is fine. However, when the user completes registration and the registration is successful:
if (success)
{
this.Close(); //('this' being the Registration form)
}
The registration form closes (good), but then the Login form minimizes and I'm not sure why. Ideally I'd like the form to stay open the entire time rather than have to click the taskbar icon to display it on-screen again.
I imagine there's more to it than the code I supplied so happy to provide more if needed. Just not sure where the issue would lie.

I've now had the same problem, which even occured when using ShowDialog(). I did some research and after taking quite some time figuring out what it was, I found that setting FormBorderStyle to System.Windows.Forms.FormBorderStyle.FixedToolWindow (or SizableToolWindow) in the main form makes this happen. I also experienced (and can reproduce) a similar issue where even the child form can get minimized if it has FixedToolWindow set, so the only "real" solution for me is to not use this borderstyle on any form.
Changing this to any other FormBorderStyle value gets rid of this issue completely, although then you obviously cannot use this borderstyle anymore.
Leaving this answer here in hopes to help other people who stumble upon this very same problem, as it apparently still exists in 2019.

Although I don't know why this happens (it shouldn't), ShowDialog() should be the better option here anyway.

You can also try showDialog(this)

Process does not kill on form close

I have just built version one of my testing application using Windows Forms. I have noticed that when running the application, it runs completely fine no hitches, exactly like the debug view. When it comes to closing the application I have noticed that the actual executable/process name hangs within Task manager and does not correctly close.
Upon further inspection I have noticed that when calling another form without hiding the previous form, a new process is spawned (kinda expected). When closing the new form (containing a few text boxes, labels and a DataGridView) the newly spawned process does not kill it's self, but remains. Then closing the main window the window disappears from the taskbar/view, but still, the processes remain active using 8,268k - 8,308k Memory
private void ClientSearch_Click(object sender, EventArgs e)
{
ClientSearch Clientsearch = new ClientSearch();
Clientsearch.Show();
}

Standard explanations for this behavior:
Hiding your main window when you display another window and forgetting to unhide it. There is no visible window anymore, nor can the user do anything to unhide it, but your app keeps motoring of course.
Starting a thread and not making sure that it is terminated when the main window closes. Setting the thread's IsBackground property to true is a workaround for that.
Calling Application.DoEvents() in your code. A very dangerous method that permits you to close the user interface but doesn't stop the loop in which it was called so the main thread of your app does not exit either.
This kind of problem is readily visible as well when you debug your app. You might have gotten in the habit of using the red rectangle on the toolbar (aka Debug + Stop Debugging) to force the debugger to quit. The Debug + Windows + Threads debugger window can provide insight into the cause of the last two bullets. Or you can use Tools + Attach to Process to attach the debugger to a zombie process.

Call
Application.Exit();
on form close/closing.
Your applications should only be creating one process per run. A new form should not be creating a new process.

How to tell whether closing via close button or via Application.Shutdown in WPF?

I added a code for standard "Are you sure you want to exit?" message inside the this.Closing
event of my main window.
It works as expected for closing from the gui, however I would like to disable this check when the application is closed via Application.Shutdown().
There is no event in the Application fired before the window gets closed and the Shutdown method cannot be overriden.
How can I detect what invoked the closing of the window?

Disclaimer: I'd make this a comment rather than an answer if I could as it is a dirty hack (not a clean one). But if you really need something and no better solutions present itself I'll post it anyway to hopefully help...
If you're definitely not in a position to control / hook the parts of the code base that are calling application shutdown, then the possibility is to find something else that responds to the shutdown that you can trip before your window closes.
My (not so ideal) thought on that is to set up another hidden window (SO: Loading a WPF Window without showing it) that the user wont interact with but the application will close on shutdown.
In the closing event of that window you can set a flag to indicate the application is shutting down. Then in your main window's closing event you can react to that flag.
The big issue to tackle is configuring things so that the hidden window will always close before the Main Window(s) safely.
I did some limited tests with MainWindow.Xaml as the application Startupuri, and creating the hidden window from the application.onstartup event and found the hidden window would close first - but I wouldn't want to gaurantee that in all scenerios! Actually getting this working and tested adequately could be a lot of work - as I said it's a last restort dirty hack.

Who calls Application.Shutdown()? If you are in Charge of that just set a flag indicating that you did it and check for that flag in the Closing event handler.

Handle PocketPC's Task Manager Stop Running programs when using nested Forms

I have a PocketPC C# application written in Visual Studio 2005. It uses nested forms (the user is presented with a form with multiple buttons, when the user selects one a new form is opened).
I've added code so that the 1st form sets it's title to string.Empty to hide it from the Running Programs List. When the 2nd form is showing and the user uses the task manager to stop my app, the 2nd form gets the on close event.
Is there any way of knowing that the close event has come from the task manager so that I can close my application? At the moment when breakpointing the close event, I'm seeing the DialogResult being set as DialogResult.OK (Which isn't helpful) and the 2nd dialog is closed returning control to caller which thinks the user selected OK and opens the next dialog.
I've Googled for info but all the helpful code such as ClosingEventArgs aren't available in the compact framework. Any ideas?

I may be missing something but if your problem is distinguishing between the 2nd dialog being closed normally, and being closed using task manager, can you not set some kind of marker when the normal close action occurs, before closing? Logically then any close event where the marker has not been set will be down to the task manager?