Usando objetos Thread-Safe

Aplica-se a: Outlook 2013 | Outlook 2016

Os aplicativos cliente podem supor que os objetos usados diretamente ou como retornos de chamada são sempre thread-safe, exceto nos seguintes casos:

  • Objeto de status de um provedor de transporte obtido por meio de uma chamada de cliente para IMAPISession::OpenEntry com um identificador de entrada da linha da tabela de status do provedor.

  • Todos os objetos de formulário MAPI obtidos por meio de uma chamada de cliente para MAPIOpenFormMgr. Os objetos de formulário obedecem às regras do modelo de apartamento e os clientes devem usá-los e todos os objetos contidos por eles somente no thread que os criou.

Quando um cliente acessa a linha de um provedor de transporte na tabela de status que inclui o identificador de entrada do objeto de status associado, o cliente pode chamar OpenEntry com esse identificador de entrada para abrir o objeto de status. Esse objeto de status não é thread-safe porque os provedores de transporte são executados no contexto do spooler MAPI e não mantêm um contexto separado para seu objeto de status. O objeto de status obedece às regras de modelo de apartamento e os clientes devem usá-lo somente no thread que o criou.

Um cliente também deve invocar MAPIInitialize em cada thread antes de usar qualquer objeto MAPI e MAPIUninitialize quando esse uso for concluído. Essas chamadas devem ser feitas mesmo se os objetos a serem usados forem passados para o thread de uma fonte externa. MAPIInitialize e MAPIUninitialize podem ser chamados de qualquer lugar, exceto de dentro de uma função Win32 DllMain , uma função invocada pelo sistema quando processos e threads são inicializados e encerrados ou em chamadas para as funções LoadLibrary e FreeLibrary .

Os objetos de uso indireto nunca devem ser considerados thread-safe. Os objetos de uso indireto são retornados por métodos que exigem ponteiros de interface de destino como parâmetros de entrada. Exemplos desses métodos são IMAPIProp::CopyTo e CopyProps, IMAPIFolder::CopyFolder e CopyMessage e IMsgServiceAdmin::CopyMsgService. Se um provedor de serviços quiser chamar esse objeto de um thread diferente daquele no qual ele foi passado, o provedor será responsável por empacotar explicitamente o objeto.