У меня есть файл .MSG, для которого я не могу изменить PR_BLOCK_STATUS (PidTagBlockStatus). Если я изменю его с помощью OutlookSpy или MFCMapi, я получаю MAPI_E_COMPUTED.Получение MAPI_E_COMPUTED при изменении PidTagBlockStatus в OutlookSpy
В Outlook также отображается сообщение об ошибке при сохранении этого сообщения (это происходит после нажатия пользователем Отображать внешние изображения, а затем закрывает сообщение, Outlook отображает диалог «Сохранить изменения?», И пользователь соглашается).
Однако PidTagBlockStatus не является вычислимым свойством. Я не понимаю, почему это происходит. У меня есть другой файл .MSG, который почти является копией первого (OutlookSpy и MFCMapi показывают, что оба файла .MSG имеют одинаковые поля/значения), но для этого файла я могу установить PR_BLOCK_STATUS. Однако эти файлы имеют разную длину, а низкоуровневые утилиты, такие как SSView, показывают, что в большем (и «рабочем») файле больше полей. Однако эти таинственные поля не отображаются в OutlookSpy или MFCMapi.
Проблема не связана с неправильной настройкой PidTagMessageDeliveryTime, так как оба сообщения (рабочие и нерабочие) имеют одно и то же значение PidTagMessageDeliveryTime (и другие поля). Сам Outlook (который знает, как правильно установить PR_BLOCK_STATUS из PidTagMessageDeliveryTime) не может завершить операцию сохранения сообщений.
«Рабочий» файл был сохранен непосредственно из Outlook «нерабочий» - с помощью стороннего программного обеспечения. Мне нужно найти способ «исправить» нерабочий файл, чтобы Outlook мог сохранить PR_BLOCK_STATUS без проблем.
Еще одна вещь. Можно просто удалить PR_BLOCK_STATUS из .MSG вообще. Это, однако, имеет эффект, который, как только пользователь щелкнул Отображать внешние изображения, Outlook правильно устанавливает PR_BLOCK_STATUS, но сообщение становится пустым в Outlook, пока оно не откроется в следующий раз. Поэтому этот метод не работает и для меня. Для этого я добавляю PR_BLOCK_STATUS к сообщению и устанавливаю его в ноль (позволяя Outlook вычислять правильное значение, если пользователь решил отображать внешние изображения). При значении по умолчанию, равном нулю, Outlook обычно показывает сообщение после щелчка «Отображать внешние изображения», но не обновляет файл .MSG при закрытии сообщения.
Другим методом будет вычисление PR_BLOCK_STATUS в состоянии «показать внешние изображения» заранее (как описано в разделе html email outlook asks to download images), но я не могу получить это, поскольку это должно быть решение пользователя для каждого конкретного сообщения, а не моего ,
Ссылки на .msg файлы (хорошо/плохо работает и/неработающих) https://dl.dropboxusercontent.com/u/18102725/msgs.zip
Использование Outlook 2010 64-бит, Windows 7 Ultimate, OutlookSpy 3,7 64-битный.
Благодарим за сообщение. Программное обеспечение создает их, не полагаясь на MAPI, генерирующий код является самодостаточным. И да, я смотрел с SSView (как упоминалось в моем оригинальном посте), и я видел разницу (но я не вижу никакой разницы в OutlookSpy или MFCMapi). И, как я сказал ранее, SSView просто позволяет мне увидеть разницу, но она слишком низкоуровневая, чтобы я мог понять что-либо из отображаемой структуры. Если вы откроете bad.msg из прикрепленного почтового индекса в OutlookSpy и попытаетесь отредактировать и сохранить PR_BLOCK_STATUS, вы получите сообщение об ошибке. – Alex
Думаю, я сразу вижу, что ни один из файлов не имеет CLSID, установленного на корневом узле. Он отличается для файлов MSG и OFT. В вашем случае это CLSID_NULL. –
Тем не менее, good.msg был сохранен непосредственно из Outlook и Outlook не имеет проблем с обновлением PR_BLOCK_STATUS в этом файле.Поэтому отсутствие CLSID не должно быть причиной проблемы. Если CLSID отсутствовал только в bad.msg, это объясняло бы проблему. – Alex