Compartir a través de

Eventos del PIA de Outlook

  • Artículo

Al examinar el ensamblado de interoperabilidad primario (PIA) de Outlook, es posible que note que muchas interfaces y muchos delegados de eventos tienen nombres que son nombres conocidos de objetos y eventos del modelo de objetos de Outlook. A diferencia de la biblioteca de tipos COM, los eventos en el PIA de Outlook no están definidos en la misma interfaz como métodos y propiedades del mismo objeto. Las interfaces, los delegados y las clases auxiliares de receptores relacionados con eventos se importan o se crean a fin de que sean compatibles con los eventos del PIA de Outlook. En este tema, se describen las interfaces, los delegados y las clases auxiliares de receptores relacionados con eventos.

Origen de interfaces, delegados y clases auxiliares de receptores de eventos

Para crear el PIA, Outlook usa el importador de la biblioteca de tipos (TLBIMP) en .NET Framework para convertir definiciones de tipo de la biblioteca de tipos COM en definiciones equivalentes de un ensamblado de Common Language Runtime (CLR). TLBIMP importa los siguientes dos tipos de interfaces para cada objeto:

TLBIMP procesa las interfaces importadas y crea varias interfaces, delegados y clases, incluida la interfaz .NET (por ejemplo, la interfaz Application). Si el objeto tiene eventos, se crea lo siguiente:

Varias versiones de eventos

Algunos objetos que existieron en varias versiones de Outlook tienen implementaciones diferentes de eventos en las distintas versiones, y se les ha agregado eventos adicionales a medida que se han publicado nuevas versiones. A fin de admitir eventos que varían según la versión, Outlook distingue estas interfaces, delegados y clases relacionados con eventos mediante la incorporación de un número de versión en el nombre. Por ejemplo:

Como es lógico, los eventos que se agregan a una versión posterior no aparecen en las interfaces de eventos de versiones anteriores y no tienen delegados correspondientes en versiones anteriores. Por ejemplo, el evento AttachmentSelectionChange se agregó al objeto Explorer en Outlook 2010 y, por lo tanto, no forma parte de las interfaces de eventos anteriores del objeto Explorer:

  • Interfaz ExplorerEvents

  • interfaz ExplorerEvents_Event

Por otro lado, puede encontrar el evento en la interfaz de eventos de .NET más reciente, ExplorerEvents_10_Event y su delegado para la versión de Outlook 2010, ExplorerEvents_10_AttachmentSelectionChangeEventHandler.

Para qué sirven las interfaces, los delegados y las clases auxiliares de receptores de eventos

Con el objeto Application como ejemplo, esta sección describe qué contienen las interfaces y clases indicadas anteriormente:

  • La interfaz principal, _Application, define todos los métodos y propiedades de Application. Salvo en un caso que se describe más adelante, esta interfaz no suele usarse en el código.

  • Las interfaces de eventos importadas por TLBIMP, como ApplicationEvents_11 y ApplicationEvents_10, definen métodos que se asignan a eventos de Application en la versión correspondiente de Outlook. Esta interfaz no se usa en el código.

  • Las interfaces de eventos creadas por TLBIMP, como ApplicationEvents_11_Event y ApplicationEvents_10_Event, definen todos los eventos de Application en la versión correspondiente de Outlook. Cuando se diseña un controlador de eventos para un evento en una versión en particular, se debe implementar el controlador de eventos como método y se debe conectar el método al evento definido en la versión correspondiente de la interfaz de eventos .NET. Salvo en un caso que se analiza a continuación, normalmente no se hace referencia a la interfaz de eventos en el código.

  • La interfaz de .NET, Application, hereda la interfaz _Application y la interfaz ApplicationEvents_11_Event. Generalmente, esta es la única interfaz que se usa en código administrado para obtener acceso al objeto, método y propiedad, y a los últimos miembros de eventos del objeto Application. No obstante, hay dos excepciones en las que para conectarse a un evento no se usa la interfaz .NET, sino una interfaz diferente:

    • Al obtener acceso a un evento que comparte el mismo nombre que un método de ese objeto, debe realizar la conversión a la interfaz de eventos adecuada para conectarse al evento. Por ejemplo, para conectarse al evento Quit , convierta a la interfaz ApplicationEvents_11_Event.

    • Al conectarse a una versión anterior de un evento que se ha ampliado posteriormente en una versión posterior de Outlook, debe conectarse a la versión del evento de la interfaz anterior. Por ejemplo, si desea conectarse a la versión del evento Quit del objeto Application implementado para Outlook 2002 en lugar de la versión más reciente, conéctese al evento Quit definido en la interfaz ApplicationEvents_10_Event, en lugar del evento Quit definido en la interfaz ApplicationEvents_11_Event.

  • Los delegados ofrecen un marco para crear controladores personalizados para eventos específicos en una versión específica de Outlook. Por ejemplo, si desea agregar una comprobación de la existencia de una línea de asunto en un elemento de Outlook justo antes de enviarlo, implemente la comprobación en un método de devolución de llamada que tenga la misma firma que el delegado, ApplicationEvents_11_ItemSendEventHandler. A continuación, enlaza el método de devolución de llamada como controlador de eventos para el evento ItemSend que se define en la interfaz ApplicationEvents_11_Event. Para obtener más información sobre cómo conectar el método callback como controlador de eventos para un objeto, consulte Conexión con controladores de eventos personalizados.

  • Las clases auxiliares de receptor creadas por TLBIMP, por ejemplo, ApplicationEvents_11_SinkHelper y ApplicationEvents_10_SinkHelper, son objetos auxiliares de eventos para eventos Application en la versión correspondiente de Outlook. No deben usarse estas clases en el código.

Vea también