Compatibilidad con subprocesos en Office
En este artículo se proporciona información sobre cómo se admite el subproceso en el modelo de objetos de Microsoft Office. El modelo de objetos de Office no es seguro para subprocesos, pero es posible trabajar con varios subprocesos en una solución de Office. aplicación de Office licaciones son servidores de Modelo de objetos componentes (COM). COM permite a los clientes 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 para que solo se ejecute un subproceso lógico en el servidor en cualquier momento. Este mecanismo se conoce como modelo de apartamento de un solo subproceso (STA). Dado que las llamadas se serializan, es posible que los autores de llamadas se bloqueen durante períodos de tiempo mientras el servidor está ocupado o controla otras llamadas en un subproceso en segundo plano.
Se aplica a: la información de este tema se aplica a proyectos de nivel de documento y proyectos de complementos de VSTO. Consulte Características disponibles por aplicación de Office lication y tipo de proyecto.
Conocimientos necesarios al usar varios subprocesos
Para trabajar con varios subprocesos, debe tener al menos conocimientos básicos sobre los siguientes aspectos de multithreading:
API de Windows
Conceptos multiproceso COM
Simultaneidad
Synchronization
Marshaling
Para obtener información general sobre multithreading, consulte Subprocesos administrados.
Office se ejecuta en el STA principal. Comprender las implicaciones de esto permite comprender cómo usar varios subprocesos con Office.
Escenario básico de multiproceso
El código de las soluciones de Office siempre se ejecuta en el subproceso principal de la interfaz de usuario. Es posible que quiera suavizar el rendimiento de la aplicación mediante la ejecución de una tarea independiente en un subproceso en segundo plano. El objetivo es completar dos tareas aparentemente a la vez en lugar de una tarea seguida por la otra, lo que debería dar lugar a una ejecución más fluida (la razón principal para usar varios subprocesos). Por ejemplo, puede tener el código de evento en el subproceso principal de la interfaz de usuario de Excel y, en un subproceso en segundo plano, podría ejecutar una tarea que recopile datos de un servidor y actualice las celdas de la interfaz de usuario de Excel con los datos del servidor.
Subprocesos en segundo plano que llaman al modelo de objetos de Office
Cuando un subproceso en segundo plano realiza una llamada a la aplicación de Office lication, la llamada se serializa automáticamente a través del límite sta. Sin embargo, no hay ninguna garantía de que la aplicación de Office lication pueda controlar la llamada en el momento en que el subproceso en segundo plano lo hace. Hay varias posibilidades:
La aplicación de Office lication debe bombear mensajes para que la llamada tenga la oportunidad de entrar. Si está realizando un procesamiento intensivo sin producir esto podría tardar tiempo.
Si otro subproceso lógico ya está en el apartamento, el nuevo subproceso no puede entrar. Esto suele ocurrir cuando un subproceso lógico entra en la aplicación de Office lication y, a continuación, realiza una llamada reentrant al apartamento del autor de la llamada. La aplicación está bloqueada esperando a que se devuelva esa llamada.
Excel puede estar en un estado de modo que no pueda controlar inmediatamente una llamada entrante. Por ejemplo, la aplicación de Office lication podría mostrar un cuadro de diálogo modal.
Para las posibilidades 2 y 3, COM proporciona la interfaz IMessageFilter . Si el servidor lo implementa, todas las llamadas entran a través del método HandleIncomingCall . Para la posibilidad 2, las llamadas se rechazan automáticamente. Para la posibilidad 3, el servidor puede rechazar la llamada, en función de las circunstancias. Si se rechaza la llamada, el autor de la llamada debe decidir qué hacer. Normalmente, el autor de la llamada implementa IMessageFilter, en cuyo caso se le notificaría el rechazo por el método RetryRejectedCall .
Sin embargo, en el caso de las soluciones creadas mediante las herramientas de desarrollo de Office en Visual Studio, la interoperabilidad COM convierte todas las llamadas rechazadas a ( COMException "El filtro de mensajes indica que la aplicación está ocupada"). Siempre que realice una llamada de modelo de objetos en un subproceso en segundo plano, debe estar preparado para controlar esta excepción. Normalmente, esto implica volver a intentarlo durante una determinada cantidad de tiempo y, a continuación, mostrar un cuadro de diálogo. Sin embargo, también puede crear el subproceso en segundo plano como STA y, a continuación, registrar un filtro de mensajes para ese subproceso para controlar este caso.
Iniciar correctamente el subproceso
Al crear un nuevo subproceso STA, establezca el estado del apartamento en STA antes de iniciar el subproceso. En el ejemplo de código siguiente se muestra cómo utilizar este recurso.
System.Threading.Thread t = new System.Threading.Thread(AnObject.aMethod);
t.SetApartmentState(System.Threading.ApartmentState.STA);
t.Start();
Para más información, consulte Procedimientos recomendados para subprocesos administrados.
Formularios modeless
Un formulario modeless permite algún 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 cerrar. El modelo de objetos de Office admite formularios de modelos administrados; sin embargo, no deben usarse en un subproceso en segundo plano.