Actually I m trying to close my window by firing the event from my ViewModel. Everything works fine and awesome, but I know that I must unsbscribe my event to avoid memory leaks. thus I implement the IDisposable interface and I unsbscribe the event inside the Dispose method.
Below is my code :
public partial class MainWindow : Window, IDisposable
{
private MainViewModel viewModel;
public MainWindow()
{
InitializeComponent();
DataContext = viewModel = new MainViewModel();
this.viewModel.RequestClose += CloseWindow;
}
void CloseWindow(object sender, EventArgs e)
{
this.Close();
}
public void Dispose()
{
////here we need to unsubscribe the event
this.viewModel.RequestClose -= this.CloseWindow;
}
}
What I need to know :
Is that code correct
When the GC will be called and excute the dispose method
Is there a better way to do such a thing
but I know that I must unsbscribe my event to avoid memory leaks
Memory leak occurs, when short-lived object subscribes an event of long-lived objects (or static event), and does not unsubscribe later (e.g., see this answer). I suppose, that this is not your case.
When the GC will be called and excute the dispose method
GC doesn't call IDisposable.Dispose (e.g., see this answer). At all.
If you haven't any code, that calls MainWindow.Dispose explicitly, it will be called never.
Is there a better way to do such a thing
I'd avoid IDisposable and events. Attached behavior here is more convenient, IMO (at least, this is reusable):
public static class WindowClosingBehavior
{
public static bool GetIsClosingInitiated(DependencyObject obj)
{
return (bool)obj.GetValue(IsClosingInitiatedProperty);
}
public static void SetIsClosingInitiated(DependencyObject obj, bool value)
{
obj.SetValue(IsClosingInitiatedProperty, value);
}
public static readonly DependencyProperty IsClosingInitiatedProperty = DependencyProperty.RegisterAttached(
"IsClosingInitiated",
typeof(bool),
typeof(WindowClosingBehavior),
new FrameworkPropertyMetadata(false, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, IsClosingInitiatedChanged));
private static void IsClosingInitiatedChanged(DependencyObject target, DependencyPropertyChangedEventArgs e)
{
var window = target as Window;
if (window != null && (bool)e.NewValue)
{
window.Close();
}
}
}
Somewhere in window's XAML:
behaviors:WindowClosingBehavior.IsClosingInitiated="{Binding IsClosingInitiated}"
where IsClosingInitiated is a property from view model:
public class SomeViewModel
{
// ...
private void Foo()
{
// ...
IsClosingInitiated = true;
}
}
You only need to unsubscribe events when the source and the handler have different lifetimes, otherwise they both go out of scope at the same time and they are garbage collected together.
So in this case IDisposable is not needed. Anyway if you implement IDisposable you need to explicitly call it, otherwise you don't have control about when it is called.
Actually when the Window.CloseWindow subscribe to the event, it makes the view model point to the window.
The reverse is also true because there is a ViewModel field in the Window.
Both window and view model reference to each other.
If there is no other reference to them, garbage collection will make the job.
Dispose will be called if some code calls it.
To my knowledge, it won't happen, unless you surround the creation of the windows with a using or explicitly call Dispose
The best way here is to not implement IDisposable / Dispose : keep it simple.
Regards
I'd say using an event is a more than acceptable method of achieving this. For a more complete dispose pattern, use the following snippet:
#region IDisposable
//Dispose() calls Dispose(true)
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// NOTE: Delete the finalizer if this class doesn't
// own unmanaged resources itself.
~ClassName()
{
//Finalizer calls Dispose(false)
Dispose(false);
}
//The bulk of the clean-up code is implemented in Dispose(bool)
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
//free managed resources (Example below)
if (managedResource != null)
{
managedResource.Dispose();
managedResource = null;
}
}
//Free native resources if there are any. (Example below)
if (nativeResource != IntPtr.Zero)
{
Marshal.FreeHGlobal(nativeResource);
nativeResource = IntPtr.Zero;
}
}
#endregion
In your case, your dispose method will be this:
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~MainWindow()
{
Dispose();
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
if (viewModel != null)
{
viewModel.RequestClose -= CloseWindow;
viewModel.Dispose();
viewModel = null;
}
}
}
As pointed out by Dennis, you'll need to keep the finalizer to ensure that Dispose gets called when the MainWindow is closed, for example in the event of the application being exited.
Related
I've noticed there are some classes on MSDN (like this one) that have a Disposing event with the following comment:
Occurs when Dispose is called or when this object is finalized and collected by the garbage collector.
I'd like to implement my own Disposing event in a class of mine. Here's my basic implementation (following the best practices for the dispose pattern):
public abstract class Handle : IDisposable
{
public bool Disposed { get; private set; }
public event System.Action DisposingCompleted;
public Handle()
{
Disposed = false;
}
~Handle()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing = false)
{
if (Disposed)
{
return;
}
if (disposing)
{
HandleManagedResources();
}
HandleUnManagedResources();
Disposed = true;
if (DisposingCompleted != null)
{
DisposingCompleted();
}
}
protected virtual void HandleManagedResources() {}
protected virtual void HandleUnManagedResources() {}
}
Someone mentioned on my Code Review that they're unsure of whether or not firing an event like this is safe because Dispose() might get called from the finalizer but, according to the comments on that MSDN link I've added at the top, it's clear that there are objects firing events when they're Disposed OR Finalized.
Am I missing something or is this safe? How does GraphicsDevice implement an event that's fired from dispose OR when finalized? If the answer is just "No, you can't do this ever" then is there any other way of achieving the same effect? (an event for an object being disposed OR finalized)
If you're going to do anything involving other objects in the Dispose methods you should only do so when Dispose is called explicitly, not when it is called from the finalizer.
The reason for this is that if that other object too is eligible for collection you have no guarantee that that object hasn't already been finalized.
I load my assembly dynamically, I create an instance of a UserControl View through Activator.CreateInstance.
classType = a.GetType(assembly + "." + constructor);
obj = Activator.CreateInstance(classType);
I have a ViewModel linked to the view. The ViewModel has a timer which it starts in the constructor.
I would like to dynamically call a method like Pause() and Resume() that stops and starts this timer.
My thoughts are that this method will have to be in the View's code-behind. I will keep the classType and obj around, so I can call the View's methods. However the way to go about informing the ViewModel to pause or resume from the code-behind without upsetting the MVVM is stumping me. Could use some advice.
[EDIT]
Ignore below has been open as a separate question: https://stackoverflow.com/questions/20572205/how-call-dispose-method-with-loaded-assembly
If I would like to dispose of an instance of this class. I have tried
var methodInfo = CurrentAssemblyClassType.GetMethod("Dispose");
var methodInfo = CurrentAssemblyClassType.GetMethod("Close");
methodInfo is null on both, not sure what to call.
public partial class Blank : UserControl, IDisposable
{
public Blank(String key)
{
InitializeComponent();
}
public void Close()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
}
}
~Blank()
{
Dispose(false);
}
#region IDisposable Members
void IDisposable.Dispose()
{
Close();
}
#endregion
}
In MVVM, the View can tell the ViewModel what to do by way of "Commands"
There is nothing special about the assembly being dynamically loaded
In my classes I implement IDisposable as follows:
public class User : IDisposable
{
public int id { get; protected set; }
public string name { get; protected set; }
public string pass { get; protected set; }
public User(int UserID)
{
id = UserID;
}
public User(string Username, string Password)
{
name = Username;
pass = Password;
}
// Other functions go here...
public void Dispose()
{
// Clear all property values that maybe have been set
// when the class was instantiated
id = 0;
name = String.Empty;
pass = String.Empty;
}
}
In VS2012, my Code Analysis says to implement IDisposable correctly, but I'm not sure what I've done wrong here.
The exact text is as follows:
CA1063 Implement IDisposable correctly Provide an overridable implementation of Dispose(bool) on 'User' or mark the type as sealed. A call to Dispose(false) should only clean up native resources. A call to Dispose(true) should clean up both managed and native resources. stman User.cs 10
For reference: CA1063: Implement IDisposable correctly
I've read through this page, but I'm afraid I don't really understand what needs to be done here.
If anyone can explain in more layman's terms what the problem is and/or how IDisposable should be implemented, that will really help!
This would be the correct implementation, although I don't see anything you need to dispose in the code you posted. You only need to implement IDisposable when:
You have unmanaged resources
You're holding on to references of things that are themselves disposable.
Nothing in the code you posted needs to be disposed.
public class User : IDisposable
{
public int id { get; protected set; }
public string name { get; protected set; }
public string pass { get; protected set; }
public User(int userID)
{
id = userID;
}
public User(string Username, string Password)
{
name = Username;
pass = Password;
}
// Other functions go here...
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// free managed resources
}
// free native resources if there are any.
}
}
First of all, you don't need to "clean up" strings and ints - they will be taken care of automatically by the garbage collector. The only thing that needs to be cleaned up in Dispose are unmanaged resources or managed recources that implement IDisposable.
However, assuming this is just a learning exercise, the recommended way to implement IDisposable is to add a "safety catch" to ensure that any resources aren't disposed of twice:
public void Dispose()
{
Dispose(true);
// Use SupressFinalize in case a subclass
// of this type implements a finalizer.
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Clear all property values that maybe have been set
// when the class was instantiated
id = 0;
name = String.Empty;
pass = String.Empty;
}
// Indicate that the instance has been disposed.
_disposed = true;
}
}
The following example shows the general best practice to implement IDisposable interface. Reference
Keep in mind that you need a destructor(finalizer) only if you have unmanaged resources in your class. And if you add a destructor you should suppress Finalization in the Dispose, otherwise it will cause your objects resides in memory longer that it should (Note: Read how Finalization works). Below example elaborate all above.
public class DisposeExample
{
// A base class that implements IDisposable.
// By implementing IDisposable, you are announcing that
// instances of this type allocate scarce resources.
public class MyResource: IDisposable
{
// Pointer to an external unmanaged resource.
private IntPtr handle;
// Other managed resource this class uses.
private Component component = new Component();
// Track whether Dispose has been called.
private bool disposed = false;
// The class constructor.
public MyResource(IntPtr handle)
{
this.handle = handle;
}
// Implement IDisposable.
// Do not make this method virtual.
// A derived class should not be able to override this method.
public void Dispose()
{
Dispose(true);
// This object will be cleaned up by the Dispose method.
// Therefore, you should call GC.SupressFinalize to
// take this object off the finalization queue
// and prevent finalization code for this object
// from executing a second time.
GC.SuppressFinalize(this);
}
// Dispose(bool disposing) executes in two distinct scenarios.
// If disposing equals true, the method has been called directly
// or indirectly by a user's code. Managed and unmanaged resources
// can be disposed.
// If disposing equals false, the method has been called by the
// runtime from inside the finalizer and you should not reference
// other objects. Only unmanaged resources can be disposed.
protected virtual void Dispose(bool disposing)
{
// Check to see if Dispose has already been called.
if(!this.disposed)
{
// If disposing equals true, dispose all managed
// and unmanaged resources.
if(disposing)
{
// Dispose managed resources.
component.Dispose();
}
// Call the appropriate methods to clean up
// unmanaged resources here.
// If disposing is false,
// only the following code is executed.
CloseHandle(handle);
handle = IntPtr.Zero;
// Note disposing has been done.
disposed = true;
}
}
// Use interop to call the method necessary
// to clean up the unmanaged resource.
[System.Runtime.InteropServices.DllImport("Kernel32")]
private extern static Boolean CloseHandle(IntPtr handle);
// Use C# destructor syntax for finalization code.
// This destructor will run only if the Dispose method
// does not get called.
// It gives your base class the opportunity to finalize.
// Do not provide destructors in types derived from this class.
~MyResource()
{
// Do not re-create Dispose clean-up code here.
// Calling Dispose(false) is optimal in terms of
// readability and maintainability.
Dispose(false);
}
}
public static void Main()
{
// Insert code here to create
// and use the MyResource object.
}
}
IDisposable exists to provide a means for you to clean up unmanaged resources that won't be cleaned up automatically by the Garbage Collector.
All of the resources that you are "cleaning up" are managed resources, and as such your Dispose method is accomplishing nothing. Your class shouldn't implement IDisposable at all. The Garbage Collector will take care of all of those fields just fine on its own.
You need to use the Disposable Pattern like this:
private bool _disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Dispose any managed objects
// ...
}
// Now disposed of any unmanaged objects
// ...
_disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Destructor
~YourClassName()
{
Dispose(false);
}
You have no need to do your User class being IDisposable since the class doesn't acquire any non-managed resources (file, database connection, etc.). Usually, we mark classes as
IDisposable if they have at least one IDisposable field or/and property.
When implementing IDisposable, better put it according Microsoft typical scheme:
public class User: IDisposable {
...
protected virtual void Dispose(Boolean disposing) {
if (disposing) {
// There's no need to set zero empty values to fields
// id = 0;
// name = String.Empty;
// pass = String.Empty;
//TODO: free your true resources here (usually IDisposable fields)
}
}
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
}
Idisposable is implement whenever you want a deterministic (confirmed) garbage collection.
class Users : IDisposable
{
~Users()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
// This method will remove current object from garbage collector's queue
// and stop calling finilize method twice
}
public void Dispose(bool disposer)
{
if (disposer)
{
// dispose the managed objects
}
// dispose the unmanaged objects
}
}
When creating and using the Users class use "using" block to avoid explicitly calling dispose method:
using (Users _user = new Users())
{
// do user related work
}
end of the using block created Users object will be disposed by implicit invoke of dispose method.
I see a lot of examples of the Microsoft Dispose pattern which is really an anti-pattern. As many have pointed out the code in the question does not require IDisposable at all. But if you where going to implement it please don't use the Microsoft pattern. Better answer would be following the suggestions in this article:
https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About
The only other thing that would likely be helpful is suppressing that code analysis warning... https://learn.microsoft.com/en-us/visualstudio/code-quality/in-source-suppression-overview?view=vs-2017
This may seem like a silly question, but I just want to make sure I have it right. My main form is not visible most of the time. To open it I have a NotifyIcon. One of the menu options is Exit Application. I also have a few static global variables that need to be disposed of before the application closes. so in program.cs i have this.
[STAThread]
static void Main()
{
InitializeApplication();
InitializeMainForm();
Application.Run(main);
}
private static void InitializeApplication()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.ApplicationExit += Application_ApplicationExit;
}
private static void InitializeMainForm()
{
main = new AssignButtonForm();
main.FormClosing += main_FormClosing;
Globals.StartNotify();
}
static void main_FormClosing(object sender, FormClosingEventArgs e)
{
var dlg = MessageBox.Show("Turn off Application?", "Exit?", MessageBoxButtons.OKCancel, MessageBoxIcon.Question, MessageBoxDefaultButton.Button1);
if (dlg == DialogResult.OK)
{
Globals.notifyIcon1.Dispose();
Application.Exit();
}
else
{
e.Cancel = true;
}
}
So what i'm hoping is that this is the correct way to call that.
private void exitToolStripMenuItem_Click(object sender, EventArgs e)
{
this.Hide();
Application.OpenForms[0].Close();
}
is that correct? or is there a better way?
EDIT
ok so one of my classes that has its own Dispose method
public class KeymonNotifyIcon : IDisposable
{
public KeymonNotifyIcon()
{
InitializeComponent();
keymonMenuStrip.SetupKeysSelected += OnSetupKeysSelected;
}
~KeymonNotifyIcon()
{
Dispose();
}
public void Dispose()
{
if (notifyIcon1 != null)
notifyIcon1.Dispose();
if (keymonMenuStrip != null)
keymonMenuStrip.Dispose();
}
}
The global class
public static class Globals
{
public static TraceSource trace = new TraceSource("Keymon");
public static KeymonNotifyIcon notifyIcon1;
public static void StartNotify()
{
notifyIcon1 = new KeymonNotifyIcon();
}
}
Actually, I am fairly certain that Application.Exit will call all of your Dispose methods for you (as long as you have implemented IDisposable
See this question, which references this question
If your program just shuts down, objects that have not been garbage collected will have their finalizers run. It is the recommended pattern that objects implementing IDisposable have a finalizer to ensure that IDisposable is run. To the best of my knowledge, .NET BCL classes always follow that pattern. However, your own or third-party/open source components might not follow that pattern.
Note: The linked pattern on MSDN does not call GC.SuppressFinalize. Check out how to use it to reduce the GC overhead.
Implementing IDisposable alone isn't sufficient to ensure that the object is properly disposed.
If you have statically referenced objects that implement IDisposable, it is a more solid solution to explicitly call IDisposable.Dispose() on them from an application shut down event.
EDIT
Your Dispose implementation will cause Dispose() to be called twice on the owned objects because:
if (notifyIcon1 != null)
notifyIcon1.Dispose();
does not set notifyIcon1 to null, and the finalizer unconditionally calls Dispose() again.
Additionally, you will always cause the finalizer to run (which makes GC more expensive for that class) because you do not call GC.SuppressFinalize() in Dispose().
So I'm working on my DI/IoC Container OpenNETCF.IoC and I've got a (reasonable) feature request to add some form of lifecycle management for IDisposable items in the container collections.
My current thinking is that, since I can't query an object to see if it's been disposed, and I can't get an event for when it's been disposed, that I have to create some form of wrapper for objects that a developer wants the framework to manage.
Right now objects can be added with AddNew (for simplicity sake we'll assume there's only one overload and there is no Add):
public TTypeToBuild AddNew<TTypeToBuild>() { ... }
What I'm considering is adding a new method (well group of them, but you get the picture):
public DisposableWrappedObject<IDisposable> AddNewDisposable<TTypeToBuild>()
where TTypeToBuild : class, IDisposable
{
...
}
Where the DisposableWrappedObject looks like this:
public class DisposableWrappedObject<T>
where T : class, IDisposable
{
public bool Disposed { get; private set; }
public T Instance { get; private set; }
internal event EventHandler<GenericEventArgs<IDisposable>> Disposing;
internal DisposableWrappedObject(T disposableObject)
{
if (disposableObject == null) throw new ArgumentNullException();
Instance = disposableObject;
}
~DisposableWrappedObject()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
lock(this)
{
if(Disposed) return;
EventHandler<GenericEventArgs<IDisposable>> handler = Disposing;
if(handler != null)
{
Disposing(this, new GenericEventArgs<IDisposable>(Instance));
}
Instance.Dispose();
Disposed = true;
}
}
}
Now, when an items gets added to the container via AddNewDIsposable, an eventhandler is also added so that when it gets Disposed (via the wrapper) the framework removes it from the underlying collection.
I actually have this implemented and it's passing the unit tests, but I'm looking for opinions on where this might be broken, or how it might be made more "friendly" to the consuming developer.
EDIT 1
Since there was a question on how the Disposing event is used, here's some code (trimmed to what's important):
private object AddNew(Type typeToBuild, string id, bool wrapDisposables)
{
....
object instance = ObjectFactory.CreateObject(typeToBuild, m_root);
if ((wrapDisposables) && (instance is IDisposable))
{
DisposableWrappedObject<IDisposable> dispInstance = new
DisposableWrappedObject<IDisposable>(instance as IDisposable);
dispInstance.Disposing += new
EventHandler<GenericEventArgs<IDisposable>>(DisposableItemHandler);
Add(dispInstance as TItem, id, expectNullId);
instance = dispInstance;
}
....
return instance;
}
private void DisposableItemHandler(object sender, GenericEventArgs<IDisposable> e)
{
var key = m_items.FirstOrDefault(i => i.Value == sender).Key;
if(key == null) return;
m_items.Remove(key);
}
Maybe I'm missing something, but why add new methods to the API? When an object is added to the container, you could as-cast to check if it's IDisposable and handle it appropriately if so.
I'm also wondering if you need the destructor. Presuming the container is IDisposable (like Unity's), you could just implement the Basic Dispose Pattern and save a lot of GC overhead.
Some questions that may be applicable:
How do you reconcile IDisposable and IoC?
Can inversion of control and RAII play together?