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()
Related
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();
}
}
In my winforms application I am trying to get a main window handle, so I can set it as parent to my wpf modal window. I am not too experienced with winforms, so after a bit of googling I found two ways to get it.
System.Windows.Forms.Application.OpenForms[0].Handle
System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle
(1) seems to always return the same value which appears to be correct (at least my modal window behaves as expected), while (2) sometimes returns the same value as (1), but sometimes - an entirely different pointer, which does not seem to work (my modal window appears on top of every other window, not just the parent window).
Can someone explain the difference between the two methods? Is it normal that sometimes they return different results?
Edit:
In case anyone else is wondering: once you get the handle, you can use it by creating WindowInteropHelper class:
public static void SetInteropParent(this Window wpfDialogWindow, IntPtr winformsParentHandle)
{
new WindowInteropHelper(wpdDialogWindow) { Owner = winformsParentHandle };
}
It is certainly not unusual for Process.MainWindowHandle to return the wrong handle. The Process class has to make a guess at which window is the "main" one. There is no mechanism in the native winapi to designate a window as such. So Process makes a guess that the first window is the main one. This has a knack for going wrong in apps that use a splash screen or a login dialog, etc, or create a window on another thread.
Application.OpenForms doesn't have this problem, but has a failure mode, it will lose track of a window when it is recreated. Which happens when the program changes certain properties of the Form that can only be specified when the window is created. The ShowInTaskbar, TransparencyKey and Opacity properties are the most common troublemakers.
The most reliable way is to override the OnHandleCreated() method of the form you want to be the parent. Which is called whenever the Handle property changes. Do note that you want to make sure that this doesn't happen while your WPF window is active, that will kill the WPF window as well. Otherwise easy to observe of course :)
protected override void OnHandleCreated(EventArgs e) {
base.OnHandleCreated(e);
SetWpfInteropParentHandle(this.Handle);
}
I have the following C# code in a WPF project:
private static void RunConfig(string owner)
{
long ownerHandle;
var settingsWindow = new SettingsWindow();
if (long.TryParse(owner, out ownerHandle))
{
WindowInteropHelper helper = new WindowInteropHelper(settingsWindow);
helper.Owner = new IntPtr(ownerHandle);
}
settingsWindow.ShowDialog();
}
The SettingsWindow isn't properly modal to the owner window (i.e. I can focus on, interact with, and even close the owner window while the SettingsWindow is still open). What am I doing wrong?
For context, this code is part of a screen saver program, and the owner window is the Control Panel screen saver selection window (which passes in the handle to use as owner via command line parameter). I know the IF statement is evaluating true and correctly parsing the handle.
I have also tried using the SetWindowLongPtr method from user32.dll (compiling for x64, hence not using SetWindowLong) which is briefly described here and shown in use here. This method works in WinForms, but doesn't seem to work here in WPF. Help me Obi-Wan Kenobi, you're my only hope.
It turns out that using WindowInteropHelper to set the native window as owner of the WPF Window does work, it just doesn't do the whole job. When set this way, the WPF Window will remain visible on top of the native window, even if the native window has focus. However, that is the only effect obtained. The WPF Window does not prevent interaction with the native Window, and the native window can even be closed, without the WPF Window closing or being affected.
In order to get the rest of the desired behaviour, we need to use the EnableWindow function in user32.dll to disable the native Window before calling ShowDialog on the WPF Window, and again to re-enable it once the WPF Window closes.
The modified code looks like this:
private static void RunConfig(string owner)
{
long ownerHandle;
var settingsForm = new SettingsWindow();
if (long.TryParse(owner, out ownerHandle))
{
WindowInteropHelper helper = new WindowInteropHelper(settingsForm);
helper.Owner = new IntPtr(ownerHandle);
NativeMethods.EnableWindow(helper.Owner, false);
settingsForm.ShowDialog();
NativeMethods.EnableWindow(helper.Owner, true);
}
else
{
settingsForm.ShowDialog();
}
}
(Note: The above code is correct in general, but incomplete in the case of screen savers, which is what this code is actually being used for. In the case that this code is being used for the config window of a screen saver, the string passed in for the owner handle is not the handle of the Control Panel window to be used as owner, but rather a handle for a control that is a child of the Control Panel window. The extra step in this case is to get the handle of the parent of that control. We can do this by calling GetParent, also in user32.dll, on the passed-in handle. This will return the real handle we want to use for the owner and EnableWindow calls.)
If anyone from Microsoft ever finds this, maybe consider modifying WindowInteropHelper to properly set all of this up when Owner is assigned and ShowDialog used, since this is the proper complete behavior for modal windows.
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 a form which instances a new form that I've already created using
statuswindow statwin = new statuswindow();
statwin.ShowDialog();
return statwin;
This code is in a function. The problem is when I run the function in other code the next line of code doesn't run until the newly instanced window is closed by the user, I'm guessing this is the side-effect of using ShowDialog(), is there a way to have it use the same behaver (being topmost, not being to select the other main window) while still letting the main form's code run?
Update: Although Show(); will work, I need to be able to make the window like a dialog by having it always on top of the other window and it always being the active selected window.
The ShowDialog method of showing a window shows it as a dialog, which is a blocking mechanism within C#/.net. If you want to simply display the window and not cause the running code to block until it is closed, you can use the window.Show() function.
In your code:
startwin.Show();
This will cause the startwin form to become visable to the user, and will fire the startwin.VisibleChanged event as well as the startwin.Load event to fire.
To make the new window always on top, you could set the Topmost window flag in the form properties.
To make the window run in a separate thread, first spawn the thread, then create the window from that thread.
There are also "application modal" and "system modal" Win32 window flags, but I don't know if those are exposed to WinForms or not -- go have a look on the form properties!