Okay, make an example here:
- I have UserControl A, UserControl B, UserControl C and one Windows Form.
- This Windows Form is only started with UserControl A.
- UserControl C has [Next] and [Back] buttons.
- Say, UserControl A is declared with an event handler. One of function in UserControl A will actually raise t开发者_高级运维he event call to execute one function at UserControl C.
- So, at UserControl C, I have to add with
"UserControlA.OneFunction += this.UserControlC_Function;"
- If I click Next button at UserControl C, it will dispose the UserControl A and add new UserControl B to the Windows Form. But I never remove this event handler manually.
One of the function in UserControl A is the caller (where event is declared).
One of the function in UserControl C is the listener.So, these are my questions:
- Should I manually remove the handler before UserControl A disposed?
- Will this User Control A dispose automatically remove the handler that declared previously?
- Should I add this somewhere?
"UserControlA.OneFunction -= this.UserControlC_Function;"
- By convention, we don't. And since no event should be invoked after disposal, there is no need to do so unless the control in question is behaving weirdly.
- No. At least there isn't such code as seen from reflector.
You don't need to remove the handlers in this case because neither the form nor its buttons are referenced by code external to the form, and the entire object graph will therefore be garbage collected.
The answer to this post does a really good job explaining when you need to manually remove an event handler and when it is not necessary.
Do I need to remove event subscriptions from objects before they are orphaned?
If the form is released (assuming no other objects has a reference to the objects in question) there's little risk of not removing the event handler, however it's a good idea always to remove the event handler before the object listening can no longer be reach (ie all variables referencing the object i sout of scope) not doing so can create a memory leak.
This is not the case in your situation (if I get what you are describing, code would make it more clear) The problem would be if you attach a delegate referencing object C to an event on object A and then looses access to C (e.g. assigning a new value to the variable). C would then hang around until A is garbage collected
If the memory lifetime of an event publisher is not limited relative to the useful lifetime of an event subscriber, failure to unsubscribe an event will likely cause a memory leak. Were it not for the unfortunate hassle of doing so, there wouldn't be any reason for an event subscriber that was being disposed not to unsubscribe from all events, and for an event publisher that was being disposed not to nullify all event subscriptions. Since neither C# nor VB provides any convenient means of doing those things, however, one has to balance the hassle of proper subscription handling with the fact that in many situations one can get away skimping on it.
精彩评论