Is there any way I could close all windows after the user closes one of them, and here is the important part: without using App.Current.Shutdown(), but rather by invoking close on remaining windows individually?
My idea was to just invoke close on each of the remaining windows in the Window_Closing event handler method. There's one problem, though. Suppose I have two window classes, A and B. I create one instance of A and B - a and b respectively. If I close window A, then it invokes the Window_closing event handler method and calls b.close() there. Then in the B class (A and B are window classes, they both inherit from Window) Window_closing method is invoked (because I've just called B.close()), and B::Window_closing calls a.close() and it results in exception cause I've already closed a.
What is the right way to solve this?
If you are interested in having a "main window" and "tool windows", so that closing the main window closes all of them and closing tool windows does, well, only just that - then in the App.xaml there's a friendly option just for that!
That's Application.ShutdownMode
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml"
ShutdownMode="OnMainWindowClose"
>
</Application>
Note that here, the "MainWindow" in question, is the main window the application starts with (or the one you set as main, if you played with that during the app's lifetime).
EDIT: afterthought: That will of course close all the windows, but I'm not actually sure if it calls normal "Close", or just shutsdown the whole application. Sorry, you'd need to check it for yourself. If you're interested in my opinion, that's the way you should/could do that easily, and if you really-really-need to shutdown the app by "Close()"ing every window, then I sense you're doing something wrong here, as if I remember correctly, "Window.Close()" may be cancelled.
EDIT2: yup, Window.Close() can be cancelled. Please see this article:
Closing a window causes the Closing event to be raised. If the Closing
event isn't canceled, the following occurs: (...)
So looping over the window collection and calling 'Close' doesn't really guarantee that the windows will really be closed and the app may still be left running afterwards.
Something like this:
private static bool WindowsClosing;
public static void CloseAllWindows()
{
if(WindowsClosing) return;
WindowsClosing = true;
var windows = Application.Current.Windows;
foreach (var wnd in windows.OfType<Window>())
{
wnd.Close();
}
}
And call that method from your Window_Closing (or rather Window_Closed if you don't need to cancel) events
Handle Window.Closedevent instead of Window.Closing which would be closing all the opened windows other than MainWindow. I am not calling Close method for MainWindow because this is the main thread which will cause application terminating.
private void Window_Closed(object sender, EventArgs e)
{
var windows = Application.Current.Windows;
foreach (var item in windows)
{
if ((item as Window).Title.ToLower() == "mainwindow") continue;
(item as Window).Close();
}
}
Related
We have an intermittent problem where an InvalidOperationException is being thrown in the ShowDialog method of a dialog window. The suspect cause is because the dialog is setting its Owner to a window which hasn't been displayed yet. This conclusion is based on the following:
The main application window (intended Owner of the dialog) instantiates and invokes ShowDialog on the dialog during its Loaded handler.
The dialog sets its Owner to the application window during its constructor
The documentation for Window.Owner says it will throw an InvalidOperationException if set to a window that hasn't been displayed yet.
We assume the (main application window) Loaded event may be fired before the window is displayed.
The exception is usually not thrown because the main application window is shown by the time the ShowDialog call is made. When the host system is under stress, the application window "Show" may be delayed, so that when ShowDialog is called, it isn't yet ready to be used as an Owner.
The question is: is this true? If so, what window event or override can be used to reliably fire after it has been displayed, so that the window may then be reliably used as the dialog's Owner, regardless of system conditions?
<Window x:Class="MyApplication.MyMainWindow"
... etc...
Loaded="OnLoaded">
... etc...
</Window>
class MyMainWindow : Window
{
private void OnLoaded(object sender, RoutedEventArgs e)
{
var dialog = new MyDialog(Application.Current.MainWindow);
dialog.ShowWindow();
}
}
class MyDialog: Window
{
public MyDialog(Window window)
{
Owner = window;
}
}
The question is: is this true?
Looks that way from inspecting the code. Programming WPF by Chris Sells & Ian Griffiths also states that the Loaded event is raised just before the window is shown.
What window event or override can be used to reliably fire after it has been displayed, so that the window may then be reliably used as the dialog's Owner, regardless of system conditions?
The ContentRendered event will be fired once, upon showing the window. I think it would be the best choice for your situation.
You can also force a Window's hWnd to be created at any time, though I'm not sure that would be enough to avoid the exception, as a created window isn't necessarily 'shown'. Still, it's a useful thing to know if you ever end up calling Win32 methods related to window management:
new WindowInteropHelper(window).EnsureHandle()
How do you use a child window in Silverlight such that it is not done asynchronous? The way you use a child window in Silverlight (so far as I know) is to use the show method:
ChildWindow update_dlg = new Update();
update_dlg.Show();
But you cannot get the input from the dialog because the call is asynchronous and keeps on running while the child window us up.
You can't, you need to listen for the child window closing then grab the dialog result.
From MSDN page:
To get the DialogResult value from a child window, handle the Closed event in the code-behind page of the calling window. In the Closed event handler, cast the sender parameter to a ChildWindow or a derived class to access the DialogResult property.
I like to pass an Action to the child window, if the user cancels the window nothing is called, if the user accepts the window the action is executed with the parameters from the window. This way the code to run when the user accepts is still written in the calling window.
There are three ways of doing this as I see it.
1) launch a seperate thread in the main app that waits until some third party class member is switched from true to false to indicate that the child window has been closed. Then in the child window, when a shutdown or OK or Cancel is done, this third party class member is switched too false etc. (this is the way i did this)
2) have a call back function in the main program that is called by the child window.
3) kind of cheat and don't have a child window at all. Instead, in the XAML code of the main window, have a rectangle that looks like a pop up or child window that is hidden (visual set to collapse) that comes up (but really becomes visual) and all other fields in the main program are set to inactive until the right butons are puched.**
I have an app that doesn't show any forms most of the time, and I needed it to close by itself when a user was shutting down the system.
So I created a question, and the answer there, SystemEvents.SessionEnding, seemed to work.
At first.
Here is my Program.Main() method:
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
#region Pre-launch stuff
// Are we upgrading from an older version? We need to grab our old settings!
if (Properties.Settings.Default.UpgradeSettings)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeSettings = false;
Properties.Settings.Default.Save();
}
// Visual styles
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
#if !DEBUG
// Add the event handler for handling UI thread exceptions to the event.
Application.ThreadException += new ThreadExceptionEventHandler(ErrorHandling.Application_ThreadException);
// Set the unhandled exception mode to force all Windows Forms errors to go through our handler.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
// Add the event handler for handling non-UI thread exceptions to the event.
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(ErrorHandling.CurrentDomain_UnhandledException);
#endif
// Since we have no forms open we need to watch for the shutdown event; otherwise we're blocking it
SystemEvents.SessionEnding += new SessionEndingEventHandler(SystemEvents_SessionEnding);
// ...
// ...
// ...
Application.Run();
}
The method SystemEvents_SessionEnding runs a method calling Exit(), which in turn runs:
public static void Exit()
{
MessageBox.Show("test");
try
{
IconHandler.SuperNotifyIcon.Dispose();
}
finally
{
Application.Exit();
}
}
And yet, my app blocks shutdown at times. And the message box that I added there doesn't show up.
I can't figure out how such a simple, simple path of execution could fail. But it does, and it's a major irritant for both me and my app's users.
Any ideas? Thoughts to throw around?
EDIT:
Per corvuscorax's answer, I've tried adding a form, but it's acted weird - at first, I had this in the form's code:
ShowInTaskbar = false;
WindowState = FormWindowState.Minimized;
Shown += (sender, e) => Hide();
And modified the Program.Exit() method to close that form, which would run the disposal code as well in the FormClosing event.
It turned out disabling ShowInTaskbar stopped the form from receiving a HWND_BROADCAST message. I've commented out that line now, but even so, I found that shutdown blocking was occurring. Once I clicked a button I made to show the form and tried to shut down again, it completed smoothly.
I would recommend against not having any forms at all.
Just do a normal WinForms application and set the main Form to be hidden and you get all the message processing working as always.
Addendum
As an added bonus of doing it this way, you also get a console for free while developing - by not hiding the main form, you can have an easy output view, simulate input, trigger actions with buttons, all sorts of useful stuff.
Addendum 2
Here's how I normally create invisible main forms. In the forms constructor, add this:
if (!Debugger.IsAttached)
{
// Prevent the window from showing up in the task bar AND when Alt-tabbing
ShowInTaskbar = false;
FormBorderStyle = FormBorderStyle.FixedToolWindow;
// Move it off-screen
StartPosition = FormStartPosition.Manual;
Location = new Point(SystemInformation.VirtualScreen.Right+10, SystemInformation.VirtualScreen.Bottom+10);
Size = new System.Drawing.Size(1, 1);
}
This will hide the window when not running from within the debugger.
Does your code have a message pump?
You need a message pump inside each user interface thread of your application so that any windows messages aimed at your application are dispatched and processed. Even if you never show a Form on the screen if the thread is a user interface thread when it will still be sent other system messages that would need to be dispatched and processed.
In a typical WinForms applications the message pump is inside this call...
Application.Run(new MyForm());
...which only exits once the MyForm instance is closed. In your case it seems you never make a call to the Application.Run method or anything similar. In which case your not handling windows messages. So what is your processing loop when you are not showing a Form?
My program puts an icon in the system tray because the user may minimize to it. However, if the application crashes, or I stop the app from running in VS it leaves the icon in it until I hover over it with the mouse. Sometimes I'll look down there and there will be 10 or so icons.
I can I make sure the icon goes away?
There is no way to do this. Windows does not poll your program to see if it's still alive. Therefore, your icon will stay in the system tray until you either tell it to leave (normal exit), or the user does something that initiates a call to your program (such as mouseover). Only then does the shell know that your program has died and it needs to clean up your icon.
You have several options:
1) Write a root structured exception handler that ensures the destruction of the icon before exit. This one takes some effort - but you can basically add your own unhandled exception handler to Windows which will be called in the case of many forms of "boom" which will then allow you some last-ditch clean up opportunity.
2) Write a monitor application that sleeps on your main processes handle, and kills the icon when it wakes up (the main application has died). To make this latter scenario work well, you'll likely want the main process to NOT kill the icon itself - or you could create a way to tell the monitor app that it should exit w/o destroying the icon (have the monitor app sleep on both the process handle and a named event - and if woken by the event then it simply dies w/o cleaning up after the main app).
Before you exit, set the NotifyIcon Visible property to false.
You need to call Dispose on the NotifyIcon for it to leave the tray.
EDIT: There's an event you can hook into in your Program.cs. For all Windows apps, you'll have something like this:
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
The Application class has a few events you can take advantage of to know when your app dies:
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.ApplicationExit += new EventHandler(Application_ApplicationExit);
I don't know what happens when one kills the process, but if it crashes due to an exception, of course one can handle it. The way to do it best, depends on the type of application: Console, Forms, a service, ...
But in all cases, you should be able to use a try / finally structure in your Program.cs, and in the 'finally' section Dispose() the TrayIcon.
For example, in a Forms application, make your NotifyIcon (called TrayIcon in my example below) in your Form class public, and change the "Application.Run(new Form1())" line in Program.cs as follows:
Form form = new Form1();
try { Application.Run(form); }
finally { form.TrayIcon.Dispose(); }
We can hide trayIcon before form closing.
Add FormClosing Event
NotifyIcon ni;
...
...
private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
ni.Visible = false;
}
I have a very strange behavior that only seems to happen on one form.
Basically I am creating an instance of a Form, and calling Show() to display the form non-blocking. In that form's Load event handler, I have some logic that may call this.Close() under certain circumstances. This closes the form, but then the form Show() method in the client code throws an ObjectDisposedException.
The stack trace from the ObjectDisposedException is as follows:
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.ContainerControl.FocusActiveControlInternal()
at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
at System.Windows.Forms.Control.Show()
...etc.
This is what I'm seeing happen:
Control.Show() is called
my form is launched
the OnFormLoad method is called
the FormLoad event handler is called, inside of which I call this.Close()
the OnFormClosing method is called
the FormClosing event handler is called
Dispose is called on my form and all it's user controls
and then somewhere toward the end of the Control.Show() method, it tries to get a handle to the form, which freaks out and throws an exception because the object is marked disposed.
My real question is, why can I do this exact same thing on every other form I have without exceptions? Is it a GC issue? I've tried putting a GC.Collect() call right after the this.Close() and it makes no difference. Like I said, it happens 100% of the time on this form, and never anywhere else, regardless of child user controls, scope of the form variable, etc.
Any ideas?
The best way to do so :
this.BeginInvoke(new MethodInvoker(this.Close));
this is the most simple way you wont get ObjectDisposedException
I know this is an old issue but no one seemed to have posted the obvoius answer.
You say you call Control.Show() and then Form.Close() and then the form is Disposed of. Well, unless you use MDI or use ShowDialog that's just as documented. Though, the short version of the Close() documentation is "Closes the form", it actually also disposes it implicitly under certain conditions.
See the remarks section:
http://msdn.microsoft.com/en-us/library/system.windows.forms.form.close.aspx
If you want to show a form again. Use the Hide() method instead of Close().
Hope that helps other searching souls.
And guys, don't stop searching at "I don't know why it works sometimes". That becomes buggy software with lots of defensive "I'll call this method again just in case" stuff. Not good.
Ok, hate to answer my own question, but this was driving me nuts, and it was one of the hardest bugs to reproduce I've ever seen.
On my form I'm overriding the OnFormLoad and OnFormClose methods, where I save/restore the form's Size, Location, and WindowState to/from the registry. I took this code out and it fixed the problem. The weird thing is, I put it back and the problem didn't come back.
I finally reproduced the problem: you have to let the form open fully, maximize it, and then close it so that the Maximized state is saved to the registry. Then when you open it again, it will set it to Maximized, and if it closes in the Load handler, it tries to access the Size/Location as it's closing. Apparently accessing these values in the OnFormClosing method causes the form to try to focus IF AND ONLY IF the form is maximized, which is illegal, since the form has been disposed.
So basically, you can't access Form display properties in the OnFormClosing method of a form, if that form is going to call Close from it's Load event.(Unless you check the Disposed prop first)
pretty specific piece of Winforms wisdom I know, but I'm writing it down anyway.
If you want to close a form as if the user pressed the cross in the upper right corner (usually means cancel), just add the following code.
this.DialogResult = System.Windows.Forms.DialogResult.Cancel;
this.Close();
This also works in the form load function:
private void MyForm_Load (object sender, EventArgs e)
{
// do some initializations
if (!ContinueLoadingForm())
{
this.DialogResult = System.Windows.Forms.DialogResult.Cancel;
this.Close();
return;
}
// continue loading the form
}
If you don't want the form to be visible for a short while, set the Visible property false (for example in the designer or constructor), and set it back to true when you are certain the program can continue loading.
In load event is not realy good idea close the form. Do it after the Activated event.
protected override void CreateHandle()
{
base.CreateHandle();
if (FormMustClose) //FormMustClose is a variable in the loadevent.
{
Close();
}
}
One possibility:
They may have a timer on this form, that is being initialized and enabled in their FormLoad event. The timer would need to be disabled and stopped as well, before the form was closed, if the timer is trying to access the form when it's fired.
I've seen forms before that do this...
It seems to me, without looking closely at it, that the cleanest way to accomplish what you want might be to make a custom form class deriving from Form, and override OnFormLoad(...) and/or Show() to check for your condition and cancel out early.
That said, I don't know why it would work sometimes and not other times.
Have you tried stepping into the .net code to see what line of code is being called when the exception is occuring? If you have VS 2008 you can do so by going to Tools --> Options --> Debugging and select the Enable .NET Framework Source Stepping. Be warned, this may take a while to download all of the necessary files, but this way you can step into the form.Show() and see exactly what is going on.
Ok, it turns out it's a little simpler and more generic than I thought, but still weird and obscure.
If you're saving/loading the form Size/Location/WindowState when the form loads/closes like we do, you have to make sure that the OnLoad method calls base.OnLoad first so that the Form Load event handler fires, and THEN set the properties. Not doing so will only cause a problem if the form calls Close from inside the Load method. You'll get an ObjectDisposedException on the Show call after the form closing event is done.
My head hurts.
Form.Shown() Is the trick too.
As I understand it, setting the DialogResult of the form will close the form - may have to be other than DialogResult.None. (i.e. you don't need to then call the Form.Close() method).
The issue is also in part that if elsewhere in code, you are accessing a property of the form or control within it, that may prevent the form from closing.
It may also be best if as has been suggested, you have a property e.g.
private bool _loadedOk = false;
in your form which you set in your initialisation code. In one of the later events after Form_Loaded, you then interrogate this and close the form if it's false.
Perhaps someone can suggest the best event to do this in??
If you want to close the form without flicker, the best way I found was override SetVisibleCore Method:
public partial class MyForm : Form
{
...
protected override void SetVisibleCore(bool value)
{
if (value && !IsHandleCreated && !ContinueLoadingForm())
{
base.SetVisibleCore(false);
this.Close();
return;
}
base.SetVisibleCore(value);
}
}
Then you can simply do:
...
var myForm = new MyForm();
myForm.Show();
...
The Form only will appear if ContinueLoadingForm() be true, this works with ShowDialog() and Application.Run() as well.
Expanding on RCMAN's answer in this thread (which got me 99% of the way to the finish line) ...
Here is the code I ended up using which also avoids the screen flicker:
Me.FormBorderStyle = FormBorderStyle.None
Me.Opacity = 0.01
Me.MinimumSize = New Size(1, 1)
Me.Size = Me.MinimumSize
Me.Location = New Point(1, 1)
BeginInvoke(New MethodInvoker(AddressOf Me.Close))
Additionally, to avoid the message "This program might not have run correctly" I applied a manifest change as described by mik here:
How to prevent "This program might not have installed correctly" messages on Vista