Compartilhar via

Suporte a encadeamento no Office

Este artigo fornece informações sobre como o threading tem suporte no modelo de objeto do Microsoft Office. O modelo de objeto do Office não é thread-safe, mas é possível trabalhar com vários threads em uma solução do Office. Os aplicativos do Office são servidores COM (Component Object Model). O COM permite que os clientes chamem servidores COM em threads arbitrários. Para servidores COM que não são thread safe, o COM fornece um mecanismo para serializar chamadas simultâneas para que apenas um thread lógico seja executado no servidor a qualquer momento. Esse mecanismo é conhecido como o modelo STA (apartamento com thread único). Como as chamadas são serializadas, os chamadores podem ser bloqueados por períodos de tempo enquanto o servidor está ocupado ou está tratando outras chamadas em um thread em segundo plano.

Aplica-se a: As informações neste tópico se aplicam a projetos no nível do documento e projetos de suplemento VSTO. Consulte os recursos disponíveis pelo aplicativo do Office e pelo tipo de projeto.

Conhecimento necessário ao usar vários threads

Para trabalhar com vários threads, você deve ter pelo menos conhecimento básico dos seguintes aspectos do multithreading:

  • Windows APIs

  • Conceitos multithread COM

  • Concurrency

  • Synchronization

  • Marshalling

    Para obter informações gerais sobre multithreading, consulte Threading Gerenciado.

    O Office é executado no STA principal. Entender as implicações disso possibilita entender como usar vários threads com o Office.

Cenário básico de multithreading

O código nas soluções do Office sempre é executado no thread principal da interface do usuário. Talvez você queira suavizar o desempenho do aplicativo executando uma tarefa separada em um thread em segundo plano. O objetivo é concluir duas tarefas aparentemente ao mesmo tempo em vez de uma tarefa seguida pela outra, o que deve resultar em uma execução mais suave (o principal motivo para usar vários threads). Por exemplo, você pode ter seu código de evento no thread principal da interface do usuário do Excel e, em um thread em segundo plano, poderá executar uma tarefa que coleta dados de um servidor e atualiza células na interface do usuário do Excel com os dados do servidor.

Threads em segundo plano que chamam o modelo de objeto do Office

Quando um thread em segundo plano faz uma chamada para o aplicativo do Office, a chamada é automaticamente gerenciada através da fronteira STA. No entanto, não há nenhuma garantia de que o aplicativo do Office possa lidar com a chamada no momento em que o thread em segundo plano a faz. Há várias possibilidades:

  1. O aplicativo do Office deve bombear mensagens para que a chamada tenha a oportunidade de entrar. Caso o sistema esteja executando um processamento pesado sem liberar recursos, isso pode demorar.

  2. Se já houver outro tópico lógico dentro do apartamento, o novo tópico não poderá entrar. Isso geralmente acontece quando um thread lógico entra no aplicativo do Office e, em seguida, faz uma chamada reentrante de volta para o apartamento do chamador. O aplicativo está bloqueado aguardando o retorno dessa chamada.

  3. O Excel pode estar em um estado de modo que não possa lidar imediatamente com uma chamada de entrada. Por exemplo, o aplicativo do Office pode estar exibindo uma caixa de diálogo modal.

    Para as possibilidades 2 e 3, o COM fornece a interface IMessageFilter . Se o servidor implementá-lo, todas as chamadas entrarão por meio do método HandleIncomingCall . Para a possibilidade 2, as chamadas são rejeitadas automaticamente. Para a possibilidade 3, o servidor pode rejeitar a chamada, dependendo das circunstâncias. Se a chamada for rejeitada, o chamador deverá decidir o que fazer. Normalmente, o chamador implementa IMessageFilter, nesse caso, ele seria notificado da rejeição pelo método RetryRejectedCall .

    No entanto, no caso de soluções criadas usando as ferramentas de desenvolvimento do Office no Visual Studio, a interoperabilidade COM converte todas as chamadas rejeitadas em um COMException ("O filtro de mensagem indicou que o aplicativo está ocupado"). Sempre que você fizer uma chamada de modelo de objeto em um thread em segundo plano, deverá estar preparado para lidar com essa exceção. Normalmente, isso envolve tentar novamente por um determinado período de tempo e, em seguida, exibir uma caixa de diálogo. No entanto, você também pode criar o thread em segundo plano como STA e, em seguida, registrar um filtro de mensagem para esse thread para lidar com esse caso.

Iniciar o thread corretamente

Ao criar um novo thread STA, defina o estado do apartamento como STA antes de iniciar o thread. O exemplo de código a seguir demonstra como fazer isso.

System.Threading.Thread t = new System.Threading.Thread(AnObject.aMethod);

t.SetApartmentState(System.Threading.ApartmentState.STA);
t.Start();

Para mais informações, confira Práticas recomendadas de encadeamento gerenciado.

Formulários sem modais

Um formulário de modelagem permite algum tipo de interação com o aplicativo enquanto o formulário é exibido. O usuário interage com o formulário e o formulário interage com o aplicativo sem fechar. O modelo de objeto do Office dá suporte a formulários de modeless gerenciados; no entanto, eles não devem ser usados em um thread em segundo plano.

Conteúdo relacionado

  • Last updated on