I have a form that the user can open from another form:
private void btnEditTemplate_Click(object sender, EventArgs e)
{
using (frmReport EditReport = new frmReport())
{
EditReport.ShowDialog();
EditReport.Close();
EditReport.Dispose();
}
}
As you can see, I've called close, dispose, and even placed the form in a using block. The form has some controls bound to static BindingLists that are maintained outside the form, and changing those lists triggers events.
Despite everything, if the user later opens another copy of this form, I am finding that events for the original form are still being run, even though it is closed and disposed.
What to do I need to do to KILL this thing? Stakes through the heart?
Update: as was indicated in the comments, the problem was the static BindingList objects were maintaining databindings to the old form. For me the solution was to get rid of the BindingList objects as I wasn't making any (intentional) use of their databinding properties anyway.
Ignoring the event handlers and data bindings at the moment, your code is little bit overkill at the moment. You could get away just this:
using (frmReport EditReport = new frmReport())
{
EditReport.ShowDialog();
}
As you are showing it as a dialog by the time it got to your .Close() call the form was closed anyway. And the using statement calls .Dispose() for you.
Now, when you dispose a form you are basically removing the form from its parent, if you have one, disposing of all child controls, and freeing up the Windows handle.
However, it does not know how to detach your event handlers and it does not know how to remove data bindings. Since these things are references into your form the garbage collector will count the form as a live object and won't try to collect it.
So if you have any handlers within your form listening to external events and they fire then your form will try to handle them.
You need to make sure that when your form closes that you detach all handlers and unbind all data bindings.
Opening the form a second time has no direct relationship to the first, but it is likely that it caused your data source to start raising events or updating values and that's what tripped your original form.
In general, I find it good practice to write event subscription code to be tolerant of being called after you unsubscribe from the event. This can happen in a variety of ways.
I don't know what experimentation you did, but for example, if you wrote this:
private void btnEditTemplate_Click(object sender, EventArgs e)
{
using (frmReport EditReport = new frmReport())
{
EditReport.ShowDialog();
EditReport.Close();
EditReport.Dispose();
}
using (frmReport EditReport2 = new frmReport())
{
EditReport2.ShowDialog();
EditReport2.Close();
EditReport2.Dispose();
}
}
then there may still be events in the message queue for the first dialog that will not get processed until you enter the modal message loop in the ShowDialog() call on the second instance.
Even with the Dispose() you have, the Garbage Collector will not reclaim the first object, because of the references to it in these subscriptions in the message queue. If you write your event subscriptions to do nothing if the object they are delivered to is already disposed, then there will be no harm done. what to check varies depending on what base class you are using. Worst case, you implement your own IsDisposed or IsClosed instance variable.
Related
In a WinForms application I have a number of instances where I add a control to a container in response to a user action (panel.Controls.Add(new CustomControl(...))), then later clear the panel (panel.Controls.Clear()) and reuse it.
In production, the app occasionally throws an exception relating to GDI errors or failing to load an ImageList. This usually happens on machines with limited resources and with users that use the application intensively over the day. It seems pretty obvious that I have a GDI handle leak and that I should be disposing the controls that get cleared from the container, however any explanations I can find are vague about where and when the control should be disposed.
Should I dispose the child controls immediately after clearing the container? Something like:
var controls = new List<Control>(_panel.Controls.Cast<Control>());
_panel.Controls.Clear();
foreach (var c in controls) c.Dispose();
Or should I track the controls in a list and call dispose in the container's Dispose() method? Such as:
List<Control> _controlsToDispose = new List<Control>();
void ClearControls()
{
_controlsToDispose.AddRange(_panel.Controls.Cast<Control>());
_panel.Controls.Clear();
}
void Dispose()
{
...
foreach (var c in _controlsToDispose) c.Dispose();
}
Option 2 introduces another list which you would need to cleanup and it will take some more memory for those items. I would prefer option 1 with a try catch wrapped around the code you mentioned.
After (somewhat effectively) correcting any cases where my app wasn't disposing cleared controls I can come up with some points:
Sometimes I've pre-built a list of controls, stored for example in the Tag property of a collection of ListViewItems or TreeViewItems. They shouldn't be disposed on clear, but the entire list should be iterated and ((Control)item.Tag).Dispose() called in the parent's Dispose() method.
If the control isn't going to be used again, which can happen when I create it on the fly, it should be disposed when it is cleared from the container.
When clearing and adding controls on the fly you need to consider the lifecycle of the controls to determine whether to dispose them immediately, defer it until the parent is being disposed, or to not worry about it.
I had a situation where I removed a control to display a 'Loading...' message, then dropped the control back in later, in response to a thread completing. I added a call to dispose the control when I removed it, which caused errors when trying to add it again. Because of the threading issue it wasn't straightforward to debug. The point is that the lifecycle can depend on threads other than the UI thread. The case in point was a matter of 20 seconds after the form was displayed, so at least the control still existed. Managing a situation where a control can be destroyed with threads still wanting to refer to it is probably a case for weak events.
I haven't been able to find any best practices or recommendations on managing control lifecycle and disposal. I guess the rule is just that if a control doesn't end it's life nested on a control that is disposed, it has to be disposed manually, whenever it isn't going to be used again, or in the parent control's Dispose() method at the latest.
I was wondering if I am doing correctly.
I instantiate a Form (let's call this Form_B) within my class (also a form) and handle Form_B's Load event. Within this event I do some initialization.
Form_B can be displayed by the user multiple times, and I call ShowDialog on my instance variable.
The problem is that the Load is called each time I show the form. I tried debugging and also tried with Show() instead of ShowDialog(). Show() fails as I closed the window but ShowDialog() does not fail, but calls Load every time it is displayed.
Is it incorrect to continue using the instance once the form is closed?
Thanks,
Stefan
Using the Load event to initialize a form is an anachronism from the VB6 days. It was really important back then, that unfortunately carried over in the design of the Winforms designer. It made Load the default event for a form.
That is however not the .NET way, you initialize a class object with the constructor. The only time you need to override OnLoad() (another .NET way, events are for code in other classes) is when you care about the size and position of the form. It won't be the design Size and Location when the user changed the Windows theme or runs the video adapter at a higher DPI setting. So you might want to use OnLoad to move the window or rearrange the controls. Not actually a very common thing to do.
So, fix your problem first by using the constructor instead. If you still need OnLoad then just use a bool flag that keeps track of whether or not it already ran.
private bool initialized = false;
protected override void OnLoad(EventArgs e) {
if (!initialized) {
initialized = true;
// etc...
}
base.OnLoad(e);
}
And yes, this only works if you use ShowDialog(). A form that's displayed with Show() automatically disposes itself when it is closed. That doesn't happen with ShowDialog() to avoid problems retrieving the dialog results. Re-creating the dialog instance is the better way, unless you really care about keeping the last entered values. That's however a really expensive way to do so, form objects take a lot of .NET and Windows resources.
That is the correct behaviour of the Load event, each time it is loaded it is called. If you want to reuse the form and avoid the the Load event, rather than close the form you should hide it and use the show method to bring it out when needed.
The load event is called once all the components of the form are loaded. If you redisplay the form, its components load again and therefore the Load event is triggered once more.
You could trigger a custom event that would only be triggered in your form's constructor if that's what you're looking for but I think it's bad practice to use a form after it's been closed.
I'm having the same problem. After searching awhile, I think the "ShowDialog" is an exception.
Since it's 2018 right now, MS has opened .Net. I've checked the source and found this.
this.CalledOnLoad = false;
this.CalledMakeVisible = false;
in the ShowDialog() function.
https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Form.cs,ab288b84e00f8282
I am trying to load a preferences window for my application and I would like the apply button to initially be disabled, then when a preference is updated, the apply button gets enabled again. I have some controls data bound to a preferences object and what happens is that after the window loads, the combobox events get triggered. Is there any event that is guaranteed to happen dead last after everything is stable?
Here is what my code looks like (the apply button is always enabled after the window loads):
private void Window_Loaded(object sender, RoutedEventArgs e)
{
_preferencesData = new PreferencesDataContext();
LayoutRoot.DataContext = _preferencesData;
ButtonApply.IsEnabled = false;
}
private void ComboBox_SelectionChanged(object sender, System.Windows.Controls.SelectionChangedEventArgs e)
{
ButtonApply.IsEnabled = true;
}
Is it also interesting to note that this only happens with textboxes and comboboxes, not checkboxes or radiobuttons.
Best solution for simple need
Joseph's answer is the best solution by far for your simple need: Just use data binding and let the data model handle it.
Answer to question as posed
There are more complex scenarios when you really do need control after absolutely everything has finished loading and all events have fired. There is no single event that occurs "dead last", but it is easy to effectively roll your own using the Dispatcher queue.
This is how to do it:
Dispatcher.BeginInvoke(DispatcherPriority.ContextIdle, new Action(() =>
{
var x = ComputeSomething(1, 2, 3);
DoSomething(x, "Test");
}));
Everything inside the { } will be executed when WPF finishes everything at a higher priority than ContextIdle, which includes all event handlers, loaded events, input events, rendering, etc.
Sequence of events when a Window is created and shown
As requested, here is the sequence of major events in WPF when a window is created and shown:
Constructors and getters/setters are called as objects are created, including PropertyChangedCallback, ValidationCallback, etc on the objects being updated and any objects that inherit from them
As each element gets added to a visual or logical tree its Intialized event is fired, which causes Styles and Triggers to be found applied in addition to any element-specific initialization you may define [note: Initialized event not fired for leaves in a logical tree if there is no PresentationSource (eg Window) at its root]
The window and all non-collapsed Visuals on it are Measured, which causes an ApplyTemplate at each Control, which causes additional object tree construction including more constructors and getters/setters
The window and all non-collapsed Visuals on it are Arranged
The window and its descendants (both logical and visual) receive a Loaded event
Any data bindings that failed when they were first set are retried
The window and its descendants are given an opportunity to render their content visually
Steps 1-2 are done when the Window is created, whether or not it is shown. The other steps generally don't happen until a Window is shown, but they can happen earlier if triggered manually.
The Window.ContentRendered event fulfilled my requirements.
I just did kind of the same thing behaviorly in a systray WPF app.
However, I didn't do it using event handling. I simply bound the Enabled property of my button to a property in my ViewModel, and had the property updated whenever I needed the behavior.
You can use ManagedSpy to figure this out on your own.
http://msdn.microsoft.com/en-us/magazine/cc163617.aspx
Setting the DataContext will likely fire the SelectionChanged event, and you can't rely on when exactly it's fired. Some logic checking on what exactly is selected would be more reliable:
private void ComboBox_SelectionChanged(object sender, System.Windows.Controls.SelectionChangedEventArgs e)
{
if (myComboBox.SelectedItem == null)
{
buttonApply.IsEnabled = false;
}
else
{
buttonApply.IsEnabled = true;
}
}
The reason it's happening afterwards with your code as-is is because the event gets queued on the thread for the UI, so it's up to Windows if it will execute the next line of code in Load, or to handle the other events on the queue.
Not to throw a whole lot of stuff at you that you may or may not be familiar with, but if this is a relatively new codebase, you may want to consider using the MVVM pattern and use Commands instead of the archaic (emphasis mine) eventing model.
Order of Events in Windows Forms
Control.HandleCreated
Control.BindingContextChanged
Form.Load
Control.VisibleChanged
Form.Activated
Form.Shown
In my C# Windows Forms application, I have a user control that contains other controls and does its own logic. One of them is a delayed call (Timer-invoked) that does certain things after the user has finished a keyboard input (live filter text). It accesses the other controls for this, one of them is that text input control. This method is invoked 500 ms after the last input event.
Now I have a problem when the delayed call is running while the application is terminating. When I enter some text, then wait about 500 ms (it seems to work every time) and then press Alt+F4 to close the window, the application throws a NullReferenceException while trying to access the text input control. This doesn't happen when I close the window immediately after the last input or a second or more after.
It seems that the control is being disposed or something and its methods cannot access the child controls anymore. So, when the control is being put in that state (by whomever and whatever that state exaclty is), those timer need to be stopped first so that the controls can be safely disposed.
I have already tried to stop the timer in the OnHandleDestroyed method (overridden) and at the beginning of the Designer-generated Dispose method. Nothing helped.
This procedure works fine in regular Forms when stopping the timers in the overridden OnFormClosed method, before calling base.OnFormClosed(). I just cannot find a suitable event in a user control.
Try this in your UserControl:
bool isDisposed;
protected override void Dispose(bool disposeManaged)
{
if(!isDisposed)
{
if(disposeManaged)
{
//Dispose your timer here
}
isDisposed = true;
}
}
Another possibility is that one of your UI classes doesn't do its cleanup. Eg. it registers itself for an event but doesn't deregister when it's manually disposed. It is never collected by the GC and when the event is fired for the next time, it tries to access some members that were set to null during the Dispose(...) call before.
Another possibility is that you have a more complex race condition within your code but it's hard to say from here.
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