Compatibilidad del subprocesamiento en Office
Actualización: noviembre 2007
En este tema se proporciona información sobre compatibilidad de subprocesamientos en el modelo de objetos de Microsoft Office. El modelo de objetos de Office no es seguro para subprocesos, pero, en una solución de Office, es posible trabajar con varios subprocesos. Las aplicaciones de Office son servidores de modelos de objetos componentes (COM). Mediante COM, los clientes pueden llamar a servidores COM en subprocesos arbitrarios. Para los servidores COM que no son seguros para subprocesos, COM proporciona un mecanismo para serializar llamadas simultáneas de modo que sólo se ejecute un subproceso lógico en el servidor en cada instante. Este mecanismo se conoce como el modelo STA (apartamento de un único subproceso). Dado que las llamadas se serializan, los llamadores pueden quedar bloqueados durante lapsos de tiempo mientras el servidor está ocupado o controlando otras llamadas en un subproceso de fondo.
Conocimientos necesarios al utilizar múltiples subprocesos
Para trabajar con varios subprocesos es necesario tener al menos un conocimiento básico de los siguientes aspectos:
APIs de Windows
Conceptos multiproceso de COM
Concurrencia
Sincronización
Cálculo de referencias
Para obtener información general acerca del subprocesamiento múltiple, vea Subprocesamiento múltiple en componentes.
Office se ejecuta en el STA principal. Entender las implicaciones que esto conlleva permite entender cómo utilizar varios subprocesos con Office.
Escenario de subprocesamiento múltiple básico
El código de Visual Studio Tools para Office siempre se ejecuta en el subproceso de la interfaz de usuario principal. Tal vez desee mejorar el rendimiento de la aplicación ejecutando una tarea independiente en un subproceso de fondo. El objetivo consiste en completar ambas tareas aparentemente al mismo tiempo en lugar de una tarea tras otra, lo que tendría como resultado una ejecución más uniforme (el motivo principal de usar múltiples subprocesos). Por ejemplo, podría tener el código de los eventos en el subproceso de la IU principal de Excel y, en un subproceso de fondo, ejecutar una tarea que recuperara datos de un servidor y actualizara las celdas en la IU de Excel con los datos obtenidos del servidor.
Subprocesos en segundo plano que realizan llamadas al modelo de objetos de Office
Cuando un subproceso de fondo realiza una llamada a la aplicación de Office, la llamada cruza automáticamente los límites del STA. Sin embargo, no hay ninguna garantía de que la aplicación de Office pueda controlar la llamada en el momento en que el subproceso de fondo la realiza. Hay varias posibilidades:
La aplicación de Office debe suministrar mensajes para que la llamada tenga la oportunidad de entrar. Si está muy ocupado en procesamientos sin resultados, esto podría llevar tiempo.
Si otro subproceso lógico ya está en el apartamento, el nuevo subproceso no puede entrar. Esto pasa a menudo cuando un subproceso lógico entra en la aplicación de Office y, a continuación, realiza una llamada que vuelve a entrar al apartamento del llamador. La aplicación se bloquea a la espera de que se devuelva la llamada.
Excel podría estar en un estado tal que no pudiera controlar inmediatamente una llamada entrante. Por ejemplo, la aplicación de Office podría estar mostrando un cuadro de diálogo modal.
Para las posibilidades 2 y 3, COM proporciona una interfaz llamada IMessageFilter. Si el servidor la implementa, todas las llamadas entran a través de un método llamado HandleIncomingCall. Para la posibilidad 2, las llamadas se rechazan automáticamente. Para la posibilidad 3, el servidor puede rechazar la llamada, dependiendo de las circunstancias. Si se rechaza la llamada, el llamador debe decidir lo que hacer. Normalmente, el llamador implementa IMessageFilter, en cuyo caso, el método RetryRejectedCall notificaría el rechazo.
Sin embargo, en el caso de Visual Studio Tools para Office, la interoperabilidad COM convierte todas las llamadas rechazadas en una excepción System.Runtime.InteropServices.COMException ("El filtro de mensaje indicó que la aplicación está ocupada"). Siempre que se realice una llamada del modelo de objetos en un subproceso de fondo, se debe estar preparado para controlar esta excepción. Normalmente, esto implica tener que reintentarlo una cierta cantidad de veces y mostrar después un cuadro de diálogo. Sin embargo, también puede crear el subproceso de fondo como STA y, a continuación, registrar un filtro de mensajes para ese subproceso para controlar este caso.
Iniciar correctamente el subproceso
Cuando cree un nuevo subproceso STA, establezca el estado de tipo apartamento en STA antes de iniciar el subproceso:
Dim t As New System.Threading.Thread(AddressOf AnObject.aMethod)
t.SetApartmentState(System.Threading.ApartmentState.STA)
t.Start()
System.Threading.Thread t = new System.Threading.Thread(AnObject.aMethod);
t.SetApartmentState(System.Threading.ApartmentState.STA);
t.Start();
Para obtener más información, vea Procedimientos recomendados para el subprocesamiento administrado.
Formularios no modales
Un formulario no modal permite cierto tipo de interacción con la aplicación mientras se muestra el formulario. El usuario interactúa con el formulario y el formulario interactúa con la aplicación sin cerrarse. El modelo de objetos de Office admite el uso de formularios no modales administrados; sin embargo, no se deben usar en un subproceso de fondo.
Vea también
Conceptos
Crear soluciones de Office en Visual Studio
Referencia
Subprocesamiento (Guía de programación de C#)
Otros recursos
Subprocesamiento múltiple en componentes