So, I've been running into a problem with many of my WPF applications where after closing children windows of a window, that window (usually my main window) will go into background, behind anything else I have open. After some research, I found this bug report submitted to Microsoft: Bug Report and their usual response of "The WPF team has recently reviewed this issue and will not be addressing it..."
Has anyone been successful at tackling this on their own? It drives me mad and I can't figure out a solution.
EDIT:
I gave some thought to what James had recommended in his answer and after almost dismissing his suggestion due to the inconvenient nature of the window being on top of everything else, I came up with this:
ChildWindow.Closed += delegate
{
ChildWindow = null;
this.Topmost = true;
System.Threading.Thread.Sleep(1000);
this.Topmost = false;
};
So, when child's Closed() event is raised, I make sure that the parent window is the topmost. Then, I let the thread sleep for 1 second and set topmost to false to allow other windows to overlay this parent window.
Reason for the pause: If I don't use a pause and just this.Topmost = true followed by this.Topmost = false, then the effect never takes place and the bug still occurs because of the timing for the bug.
I'm not sure if it's the best way, but it works. Microsoft needs to invest more resources into WPF.
set the Main window to:
Topmost=true
This should help a little, but will not solve the issue entirely. Just keep in mind that if another application has the setting, they could end up on top of the application anyways. Let me know if this helps.
I would just have left a comment under the question, but I don't have enough reputation.
I encountered this very same issue, and after playing a little bit with the solution presented here, realized that a cleaner solution would be to call Focus() on the parent instead of making it topmost, set a timer, then remove topmost:
ChildWindow.Closed += delegate
{
ChildWindow = null;
parentWindow?.Focus();
};
This bug is indeed really annoying since it does not occur all the time and can sometimes be hard to reproduce. I know the OP asked about WPF but here is my workaround for WinForms so far (I prefered to avoid the Thread.Sleep(1000) so that the UI remains responsive):
ChildWindow.Closed += delegate { this.Activate(); };
I have a tricky problem here that I have not been able to solve and neither have the people I asked on msdn forums.
I am using a third part product (signal lab from mitov.com) which is a set of .net components.
I have created a windows form app that works fine if it is run.
I now want to show this form from another form when this other form loads (or shows, or activates...).
I already have examples of this working with another form: Here is the typical code:
I am loading a form (SecondForm) from the main program...
private void SecondForm_Load(object sender, EventArgs e)
{
Form _macros = new Macros(this); //this works perfectly fine
_macros.show(this);
//this is where I have no success
Form _spectrum = new SpectrumScope;
_spectrum.Show();
}
I get various errors from no form displayed and then an exception about not instantiating the _spectrum, to an error about cross threaded operation not being allowed, to a blue screen with a message about clocks not being synchronized between processors.
If I place a button on "Second Form" and add the show form code to the click event, it works fine.
If I try to use form.activated, or form shown instead of form.load there is not difference.
If I add a time to form Shown, which then does a button.performClick, there is no difference.
Obviously the form which contains many components (and many threads behind the scene) does not like the fact that it is not being opened by the user.
I'm fairly new to C# and I'm pretty sure this is threading related.
Thank you for any help.
Try the blow code in your form load method, that should let .Net manage the threading for you.
this.Invoke(new MethodInvoker(() => (new SpectrumScope).Show()));
Well, the problem is fixed. However, I don't really know why the issue exists.
In the spectrum form I reference static variables in the secondform. Now, I use them as follows:
string newFrequency = secondForm.frequency;
This works. However, some of these variables need to have this done:
string newBandWidth = secondForm.bandwidth.substring(2,4);
This is the command that fails. I am told I need the "new" keywork.
I changed my code provide the the string without the need to get the substring and now it all works ok.
Anybody have any ideas?
The AxAcroPDF swallows all key-related events as soon as it gets focus, including shortcuts, key presses, etc. I added a message filter, and it doesn't get any key-related messages either. It's a COM component, could that be relevant?
Is there any way to catch these before the control starts swallowing them?
Hans is correct, the Acrobat Reader spawns two child AcroRd32 processes which you have no direct access to from within your managed code.
I have experimented with this and you have three viable options:
You can create a global system hook, and then look for and filter out / respond to WM_SETFOCUS messages sent to your child AcroRd32 windows. You can accomplish some of this from within C# by using a wrapper library, such as the one here: http://www.codeproject.com/KB/system/WilsonSystemGlobalHooks.aspx
You also need to identify the correct processes as there may be more than one instance of your application, or other instances of AcroRd32. This is the most deterministic solution, but because your application will now be filtering messages sent to every single window in existence, I generally don't recommend this approach because then your program could negatively affect system stability.
Find an alternate PDF viewing control. See this answer for a few commercial components: .net PDF Viewer control , or roll your own: http://www.codeproject.com/KB/applications/PDFViewerControl.aspx
Find an acceptable hack. Depending on how robust your application needs to be, code such as the following may be suitable (it was suitable for my case):
DateTime _lastRenav = DateTime.MinValue;
public Form1()
{
InitializeComponent();
listBox1.LostFocus += new EventHandler(listBox1_LostFocus);
}
private void listBox1_SelectedIndexChanged(object sender, EventArgs e)
{
axAcroPDF1.src = "sample.pdf"; //this will cause adobe to take away the focus
_lastRenav = DateTime.Now;
}
void listBox1_LostFocus(object sender, EventArgs e)
{
//restores focus if it were the result of a listbox navigation
if ((DateTime.Now - _lastRenav).TotalSeconds < 1)
listBox1.Focus();
}
I might finally have a ridiculously simple answer. So far in testing this is working.
Having suffered from this problem for quite some time and having built a complex system of each custom control recording which of them last had focus and using a timer to flip focus back (when acropdf grabbed it) I revisited this problem and read a great number of answers (looking for recent solutions). The information gleaned helped me with the idea.
The idea is to disable the (acropdf) control whilst it is loading as in the following example (code reduced for clarity)
AxAcroPDF_this.Enabled = False
AxAcroPDF_this.src = m_src
Then on a timer, after say 1 second.
AxAcroPDF_this.Enabled = True
Basically the idea is to tell Windows not to let users use the acropdf control until allowed, so asking Windows to prevent it from getting focus (because users are not allowed in there).
So far this is holding up, I will edit this if anything changes. If it doesn't work completely for you then maybe the idea points into a useful direction.
It is an out-of-process COM component, that's the problem. Completely in violation of Windows SDK requirements as laid out in SetParent(). Once its window gets the focus, the message loop in the acroread.exe process gets all the messages, your message filter cannot see any messages anymore.
Technically it is fixable by using SetWindowsHookEx() to inject a DLL into the process and monitor messages with WH_GETMESSAGE. But you can't write such a DLL in the C# language.
Major suck, I know. There never seems to be any lack of it with that program.
For some reason Tim's answer, disabling the AxAcroPDF control directly, didn't work in my case. The Leave event on the previously-selected Textbox would never fire, either.
What is working is nesting the AxAcroPDF control inside of a disabled GroupBox. Since the users of my application need to only see the PDF, not interact with it, the GroupBox's Enabled property is set to False in the designer.
I wrote an alarm app with some complex code i dont feel like breaking up right now to use as an example. I have a timer checking every 10 or so minutes about a state online and on certain conditions my app alerts me. On form_load i set the timer to 10mins and when it triggers and the condition is true i call a function with this in it.
{
this.WindowState = FormWindowState.Maximized;
this.TopMost = true;
this.Activate();
}
When i start the app i typically minimize it and do whatever. Today i notice it isnt working. On my initial test i call the code after pulling the states and calling the func on form_load which always brought it up but now that i am doing other things and the window has been minimized i notice it did not work. How do i fix this?
Are you hiding the form? In which case try this.Show() instead.
Additionally, form_load runs once (usually). You want form_activated. The form is in memory (loaded) whether or not it's minimized.
And, including a call to the activate event in your form_load event is redundant.
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