Diseño de eventos
Los eventos son mecanismos que permiten al código específico de la aplicación ejecutarse cuando se produce una acción. Los eventos se pueden producir antes de que ocurra la acción asociada (eventos anteriores) o después de ella (eventos posteriores). Por ejemplo, cuando un usuario hace clic en un botón de una ventana, se inicia un evento posterior que permite que se ejecuten los métodos específicos de la aplicación. Un delegado del controlador de eventos se enlaza al método que se va a ejecutar cuando el sistema inicia un evento. El controlador de eventos se agrega al evento para que pueda invocar a su método cuando se provoca el evento. Eventos pueden tener datos específicos de eventos (por ejemplo, un evento de presionar el botón del mouse puede incluir datos sobre la ubicación del cursor de la pantalla).
La firma del método de control de eventos es idéntica a la firma del delegado del controlador de eventos. La firma del controlador de eventos sigue estas convenciones:
El tipo de valor devuelto es Void.
El primer parámetro se denomina sender y es del tipo Object. Éste es el objeto que provocó el evento.
El segundo parámetro se denomina e y es de tipo EventArgs o una clase derivada de EventArgs. Estos son los datos específicos del evento.
El método toma exactamente dos parámetros.
Para obtener más información sobre los eventos, vea Controlar y provocar eventos.
Para los eventos, utilice el término provocar o iniciar en lugar de disparar o desencadenar.
Utilice System.EventHandler<T> en lugar de crear manualmente nuevos delegados que se van a utilizar como controladores de eventos.
Esta instrucción se refiere principalmente a las áreas de nuevas funciones. Si está expandiendo la funcionalidad en un área que ya utiliza controladores de eventos no genéricos, puede continuar utilizando controladores de eventos no genéricos para mantener la coherencia del diseño.
No puede cumplir esta instrucción si su biblioteca tiene como destino versiones de .NET Framework que no admiten eventos genéricos.
Considere la posibilidad de usar una clase derivada de System.EventArgs como argumento del evento, a menos que tenga la absoluta seguridad de que nunca será necesario que el evento entregue ningún dato al método de control de eventos, en cuyo caso puede utilizar directamente el tipo System.EventArgs.
Si define un evento que toma una instancia de EventArgs en lugar de una clase derivada que defina usted, no podrá agregar datos al evento en versiones posteriores. Por esa razón, es preferible crear una clase derivada vacía de EventArgs. Esto le permitirá agregar datos al evento en versiones posteriores sin introducir cambios importantes.
Utilice un método virtual protegido para provocar cada evento. Esto sólo es aplicable a los eventos no estáticos de clases no selladas, no a estructuras, clases selladas ni eventos estáticos.
Al cumplir esta instrucción se permite a las clases derivadas controlar un evento de clase base reemplazando el método protegido. El nombre del método virtual protegido (Overridable en Visual Basic) debería ser igual que el nombre de evento que tiene el prefijo On. Por ejemplo, el método virtual protegido para un evento llamado "TimeChanged" se denomina "OnTimeChanged".
.gif "Nota importante") Importante |
|---|
No se requiere que las clases derivadas que reemplazan el método virtual protegido llamen a la implementación de la clase base.La clase base debe continuar funcionando correctamente aun cuando no se llame a su implementación. |
Utilice un parámetro que tenga el mismo tipo que la clase de argumento de evento para el método protegido que inicia un evento. El parámetro se debería denominar e.
La clase FontDialog proporciona el método siguiente, que provoca el evento Apply:
Protected Overridable Sub OnApply( ByVal e As EventArgs )
protected virtual void OnApply(EventArgs e);
No pase null (Nothing en Visual Basic) como parámetro remitente (sender) al iniciar un evento no estático.
En eventos estáticos, el parámetro sender debería ser null (Nothing en Visual Basic).
No pase null (Nothing en Visual Basic) como parámetro de datos del evento al iniciar un evento.
Si no hay ningún dato de eventos, pase Empty en lugar de null.
Prevea la ejecución arbitraria de código en el método de control de eventos.
Considere la posibilidad de colocar el código desde el que se provoca el evento en un bloque try-catch para impedir la finalización del programa a causa de excepciones no controladas iniciadas desde los controladores de eventos.
Plantéese iniciar eventos que pueda cancelar el usuario final. Esto sólo es aplicable a los eventos anteriores.
Si está diseñando un evento cancelable, utilice CancelEventArgs en lugar de EventArgs como la clase base para el objeto de datos de eventos e.
Portions Copyright 2005 Microsoft Corporation. Reservados todos los derechos.
Portions Copyright Addison-Wesley Corporation. Reservados todos los derechos.
Para obtener más información sobre las directrices de diseño, consulte “las instrucciones de diseño de Framework: Convenciones, frases realizadas y modelos para libro de bibliotecas reutilizables de .NET” de Krzysztof Cwalina y Brad Abrams, publicados por Addison-Wesley, 2005.
Vea también
Conceptos
Diseño de controladores de eventos personalizados
Otros recursos
Instrucciones de diseño de miembros
Instrucciones de diseño para desarrollar bibliotecas de clases