c# - example - ¿Debo desconectar siempre los controladores de eventos en el método Dispose?
publish event c# (2)
A menos que espere que el editor del evento sobreviva al suscriptor, no hay razón para eliminar el controlador de eventos, no.
Este es uno de esos temas donde la tradición popular ha crecido. Realmente solo necesita pensar en términos normales: el editor (por ejemplo, el botón) tiene una referencia al suscriptor. Si tanto el editor como el suscriptor serán elegibles para la recolección de basura al mismo tiempo de todos modos (como es común) o si el editor será elegible para la recolección de basura antes , entonces no hay un problema de GC.
Los eventos estáticos causan un problema de GC porque en realidad son editores de larga duración infinita: desalentaría por completo los eventos estáticos, siempre que sea posible. (Raramente los encuentro útiles)
El otro problema posible es si explícitamente desea dejar de escuchar eventos porque su objeto se comportará mal si el evento se plantea (por ejemplo, intentará escribir en un flujo cerrado). En ese caso, sí, debe eliminar el controlador. Es más probable que sea en el caso en que su clase implementa IDisposable ya. Sería inusual, aunque no imposible, que valga la pena implementarlo para poder eliminar los controladores de eventos.
Estoy trabajando en C # y mi lugar de trabajo tiene algunos estándares de código. Una de ellas es que cada controlador de eventos que conectamos (como KeyDown ) se debe desconectar en el método Dispose . ¿Hay alguna buena razón para eso?
Tuve una fuga importante de GDI en mi aplicación si no cancelaba el registro de los controladores de eventos en Dispose () de un control de usuario que se creaba y destruía dinámicamente. Encontré lo siguiente en la ayuda de Visual Studio 2013, en la Guía de programación C #. Tenga en cuenta las cosas que he puesto en cursiva:
Cómo: suscribirse y cancelar suscripción a eventos
...recorte... Darse de baja Para evitar que se invoque su controlador de eventos cuando se produce el evento, anule la suscripción del evento. Para evitar pérdidas de recursos, debe darse de baja de los eventos antes de deshacerse de un objeto suscriptor. Hasta que se da de baja de un evento, el delegado de multidifusión que subyace al evento en el objeto de publicación tiene una referencia al delegado que encapsula el controlador de eventos del suscriptor. Siempre que el objeto de publicación contenga esa referencia, la recolección de basura no eliminará su objeto de suscriptor.
Tenga en cuenta que, en mi caso, tanto el editor como el suscriptor pertenecían a la misma clase y los controladores no son estáticos.