Entfernen benutzerdefinierter Formulardefinitionen, die mit einer Nachricht gespeichert wurden
Gilt für: Outlook 2013 | Outlook 2016
Dieses Thema zeigt ein Codebeispiel in C++, das eine Nachricht, die mit einer benutzerdefinierten Formulardefinition gespeichert wurde, in eine reguläre Nachricht ohne formulardefinition konvertiert.
In Microsoft Outlook 2010 oder Microsoft Outlook 2013 können Sie Formulare freigeben, die benutzerdefinierte Formularseiten enthalten, indem Sie sie entweder in einer Formularbibliothek veröffentlichen oder die entsprechende Formulardefinition mit einer Nachricht speichern. Ein benutzerdefiniertes Formular, das mit einer Nachricht gespeichert wird, wird häufig als "einmaliges Formular" bezeichnet, da das Formular nur zum Anzeigen dieser bestimmten Nachricht als einmaliges instance freigegeben wird. Dies geschieht in der Regel, wenn das Formular nicht in einer Formularbibliothek veröffentlicht wird, der Empfänger aber das benutzerdefinierte Formular beim Öffnen des Elements verwenden soll. Sie können angeben, dass ein Formular im formularbasierten Designer einmalig ist, indem Sie auf der Seite Eigenschaften des Formulars das Kontrollkästchen Formulardefinition mit Element senden aktivieren.
Formulare, die Formularseiten enthalten, können mit Code in Visual Basic Scripting Edition (VBScript) angepasst werden. Nachrichten, die mit Formulardefinitionen gespeichert werden, sind im Allgemeinen größer. Aus Sicherheits- und Speichergründen ignorieren Outlook 2010 und Outlook 2013 Formulardefinitionen, die mit einem beliebigen Element gespeichert wurden.
Um eine Nachricht, die mit einer benutzerdefinierten Formulardefinition gespeichert wird, in eine Nachricht ohne zu konvertieren, müssen Sie vier benannte Eigenschaften entfernen:
Darüber hinaus sollten Sie auch die kanonische PidLidPropertyDefinitionStream-Eigenschaft entfernen, die die Definitionen der mit dieser Nachricht gespeicherten benutzerdefinierten Eigenschaften enthält. Ein Nebeneffekt des Entfernens dieser Eigenschaft ist, dass die Outlook 2010- oder Outlook 2013-Objektmodelle und die Outlook 2010- oder Outlook 2013-Benutzeroberfläche nicht mehr auf Benutzereigenschaften zugreifen können, die für die Nachricht festgelegt wurden. Sie können weiterhin auf diese Eigenschaften und ihre Werte über MAPI zugreifen. Wenn Sie diese Eigenschaft nicht entfernen und die Nachricht mit einer anderen Formulardefinition gespeichert wird, wird die kanonische PidLidPropertyDefinitionStream-Eigenschaft teilweise mit neuen Daten überschrieben, und die Datenintegrität ist nicht garantiert.
Wenn Sie die kanonische PidLidPropertyDefinitionStream-Eigenschaft entfernen, sollten Sie auch das INSP_PROPDEFINITION-Flag aus der kanonischen PidLidCustomFlag-Eigenschaft entfernen.
Die folgende Funktion akzeptiert RemoveOneOffals Eingabeparameter einen Zeiger auf eine Nachricht und einen Indikator, ob die kanonische PidLidPropertyDefinitionStream-Eigenschaft entfernt werden soll. Mithilfe des Nachrichtenzeigers wird IMAPIProp::GetIDsFromNames aufgerufen, um die entsprechenden Eigenschaftenbezeichner abzurufen. Anschließend wird IMAPIProp::D eleteProps aufgerufen, um die benannten Eigenschaften zu entfernen. Außerdem wird IMAPIProp::GetProps aufgerufen, um die kanonische PidLidCustomFlag-Eigenschaft abzurufen, und das INSP_ONEOFFFLAGS-Flag und INSP_PROPDEFINITION Flag werden entsprechend aus dieser Eigenschaft gelöscht, sodass Outlook 2010 und Outlook 2013 nicht nach den benannten Eigenschaften suchen, die entfernt wurden.
ULONG aulOneOffIDs[] = {dispidFormStorage,
dispidPageDirStream,
dispidFormPropStream,
dispidScriptStream,
dispidPropDefStream, // dispidPropDefStream must remain next to last in list
dispidCustomFlag}; // dispidCustomFlag must remain last in list
#define ulNumOneOffIDs (sizeof(aulOneOffIDs)/sizeof(aulOneOffIDs[0]))
HRESULT RemoveOneOff(LPMESSAGE lpMessage, BOOL bRemovePropDef)
{
if (!lpMessage) return MAPI_E_INVALID_PARAMETER;
HRESULT hRes = S_OK;
MAPINAMEID rgnmid[ulNumOneOffIDs];
LPMAPINAMEID rgpnmid[ulNumOneOffIDs];
LPSPropTagArray lpTags = NULL;
ULONG i = 0;
for (i = 0 ; i < ulNumOneOffIDs ; i++)
{
rgnmid[i].lpguid = (LPGUID)&PSETID_Common;
rgnmid[i].ulKind = MNID_ID;
rgnmid[i].Kind.lID = aulOneOffIDs[i];
rgpnmid[i] = &rgnmid[i];
}
hRes = lpMessage->GetIDsFromNames(
ulNumOneOffIDs,
rgpnmid,
0,
&lpTags);
if (lpTags)
{
// The last prop is the flag value
// to be updated, don't count it
lpTags->cValues = ulNumOneOffIDs-1;
// If the prop def stream is not to be removed, don't count it
if (!bRemovePropDef)
{
lpTags->cValues = lpTags->cValues-1;
}
hRes = lpMessage->DeleteProps(
lpTags,
0);
if (SUCCEEDED(hRes))
{
SPropTagArray pTag = {0};
ULONG cProp = 0;
LPSPropValue lpCustomFlag = NULL;
// Grab dispidCustomFlag, the last tag in the array
pTag.cValues = 1;
pTag.aulPropTag[0] = CHANGE_PROP_TYPE(
lpTags->aulPropTag[ulNumOneOffIDs-1],
PT_LONG);
hRes = lpMessage->GetProps(
&pTag,
fMapiUnicode,
&cProp,
&lpCustomFlag);
if (SUCCEEDED(hRes) &&
1 == cProp && lpCustomFlag &&
PT_LONG == PROP_TYPE(lpCustomFlag->ulPropTag))
{
// Clear the INSP_ONEOFFFLAGS bits so Outlook
// doesn't look for the props that have been deleted
lpCustomFlag->Value.l =
lpCustomFlag->Value.l & ~(INSP_ONEOFFFLAGS);
if (bRemovePropDef)
{
lpCustomFlag->Value.l =
lpCustomFlag->Value.l & ~(INSP_PROPDEFINITION);
}
hRes = lpMessage->SetProps(
1,
lpCustomFlag,
NULL);
}
hRes = lpMessage->SaveChanges(KEEP_OPEN_READWRITE);
}
}
MAPIFreeBuffer(lpTags);
return hRes;
}