Tabelas de anexos

Aplica-se a: Outlook 2013 | Outlook 2016

Uma tabela de anexos contém informações sobre todos os objetos de anexo associados a uma mensagem enviada ou a uma mensagem em composição.

Somente os anexos que foram salvos por meio de uma chamada para o método IMAPIProp::SaveChanges da mensagem são incluídos na tabela. As tabelas de anexo são implementadas por provedores de repositório de mensagens e usadas por aplicativos cliente e provedores de transporte.

Uma tabela de anexos pode ser acessada chamando um dos seguintes:

• IMessage::GetAttachmentTable

• IMAPIProp::OpenProperty, solicitando a propriedade PR_MESSAGE_ATTACHMENTS (PidTagMessageAttachments).

As tabelas de anexo são dinâmicas.

Os provedores do repositório de mensagens não são obrigados a dar suporte à classificação em suas tabelas de anexos. Se não houver suporte para classificação, a tabela deverá ser apresentada em ordem por posição de renderização — a propriedade PR_RENDERING_POSITION (PidTagRenderingPosition).

Os provedores de repositório de mensagens também não são obrigados a dar suporte a restrições em suas tabelas de anexos. Os provedores que não dão suporte a restrições retornam MAPI_E_NO_SUPPORT de suas implementações de IMAPITable::Restrict e IMAPITable::FindRow.

As mesas de anexo podem ser pequenas; Há apenas quatro colunas no conjunto de colunas necessárias:

• PR_ATTACH_NUM (PidTagAttachNumber)

• PR_INSTANCE_KEY (PidTagInstanceKey)

• PR_RECORD_KEY (PidTagRecordKey)

• PR_RENDERING_POSITION

PR_ATTACH_NUM é intransmissível e contém um valor para identificar exclusivamente um anexo em uma mensagem. Esta propriedade é frequentemente usada como um índice nas linhas da tabela. PR_ATTACH_NUM tem uma vida útil curta; Ele é válido apenas enquanto a mensagem que contém o anexo estiver aberta. Seu valor tem a garantia de permanecer constante enquanto a tabela de anexos estiver aberta.

PR_INSTANCE_KEY é necessário em quase todas as tabelas. Ele é usado para identificar exclusivamente uma linha específica.

PR_RECORD_KEY é comumente usado para identificar exclusivamente um objeto para fins de comparação. Ao contrário do PR_ATTACH_NUM, PR_RECORD_KEY tem o mesmo escopo de um identificador de entrada de longo prazo; Ele permanece disponível e válido mesmo depois que a mensagem é fechada e reaberta. Para obter mais informações sobre o uso de chaves de registro no MAPI, consulte Chaves de registro e pesquisa MAPI.

PR_RENDERING_POSITION indica como um anexo deve ser exibido em uma mensagem de rich text. Ele pode ser definido como um deslocamento em caracteres, com o primeiro caractere do conteúdo da mensagem armazenado na propriedade PR_BODY (PidTagBody) sendo deslocado 0, ou como -1 (0xFFFFFFFF), indicando que o anexo não deve ser renderizado dentro do texto da mensagem. Não definir PR_RENDERING_POSITION também é uma opção.

Quando uma tabela de anexos é classificada por posição de renderização, o provedor do repositório de mensagens a trata como um valor assinado (PT_LONG). Portanto, os anexos com posições de renderização de -1 são classificados antes dos anexos com posições de renderização que refletem deslocamentos válidos.

Para obter mais informações sobre como renderizar um anexo em uma mensagem de texto sem formatação, consulte Renderizando um anexo em texto sem formatação.

Para obter informações sobre como renderizar um anexo em texto formatado, como RTF (Formato Rich Text), consulte Renderizando um anexo em texto RTF.

Algumas das propriedades que os provedores de repositório de mensagens geralmente incluem em uma tabela de anexo porque são fáceis de calcular ou recuperar:

Confira também

• Tabelas MAPI