Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.