Änderungen an benutzerdefinierten Eigenschaften in Outlook

Bewährte Methode: Programmgesteuertes Hinzufügen benutzerdefinierter Felder

Verschiedene APIs können zum programmgesteuerten Hinzufügen benutzerdefinierter Felder zu Elementen verwendet werden. Verwenden Sie dazu die UserProperties.Add-Methode in der Outlook-Objektbibliothek ("Outlook.Application"). Der folgende Code veranschaulicht diese bewährte Methode.

Set myProp = myItem.UserProperties.Add("MyPropName", olText)

Sie können auch die CDO-Objektbibliothek ("MAPI. Sitzung), um benutzerdefinierte Felder hinzuzufügen. Weitere Informationen finden Sie auf der folgenden MSDN-Website:

http://msdn2.microsoft.com/en-us/library/ms527518.aspx Für C++-Entwickler kann die erweiterte MAPI verwendet werden, um benannte Eigenschaften hinzuzufügen. Weitere Informationen finden Sie auf der folgenden MSDN-Website:

http://msdn2.microsoft.com/en-us/library/ms529684.aspx

Bewährte Methode: Verwenden von veröffentlichten benutzerdefinierten Formularen, die benutzerdefinierte Felder enthalten

Outlook vertraut weitgehend veröffentlichten benutzerdefinierten Formularen. Outlook vertraut jedoch nicht veröffentlichten Formularen oder einmaligen Formularen nicht. Dies schließt OFT-Dateien ein. Daher wird beim Entwerfen einer benutzerdefinierten Formularlösung dringend empfohlen, das benutzerdefinierte Formular zu veröffentlichen. Sie sollten das Formular so entwerfen, dass das Formular nicht zu einem einmaligen Formular wird. Solange ein Formular veröffentlicht wird, ist das Formular von der Änderung in Outlook nicht betroffen.
 
Wenn Sie eine OFT-Datei in einem anderen Speicher veröffentlichen, können Sie mit dem Standardspeicher Eigenschaften in diesem Speicher erstellen. Wenn Sie ein benutzerdefiniertes Formular mit benutzerdefinierten Eigenschaften erstellen und es in der entsprechenden Formularbibliothek oder im entsprechenden Ordner veröffentlichen, werden die benutzerdefinierten Eigenschaften in den betroffenen Speichern erstellt.

Bewährte Methode: Programmgesteuertes Bereitstellen von benutzerdefinierten Formularen

Wenn Sie ein benutzerdefiniertes Outlook-Formular entwickeln, das von anderen verwendet wird, gibt es einige Ansätze, die Sie verwenden können. Der ansatz, den Sie verwenden, hängt von mehreren Faktoren ab. Zu diesen Faktoren gehören der Typ des Formulars, wer das Formular verwendet, wo das Formular verwendet wird usw. Wenn ein benutzerdefiniertes Formular von vielen Personen verwendet wird, empfiehlt es sich in der Regel, das Formular in der Organisationsformularbibliothek zu veröffentlichen. Wenn dies jedoch nicht möglich ist, können Sie das Formular in einem freigegebenen Ordner oder in der Persönlichen Formularbibliothek einiger Benutzer veröffentlichen. Sie können ein benutzerdefiniertes Formular programmgesteuert mithilfe der CreateItemFromTemplate-Methode in der Outlook-Objektbibliothek installieren. Sie verwenden die CreateItemFromTemplate-Methode, um eine OFT-Datei zu öffnen und dann das Formular mit der PublishForm-Methode zu veröffentlichen. In diesem Fall ist eine OFT-Datei von den Änderungen der benutzerdefinierten Eigenschaften nicht betroffen.

Nicht empfohlen: Bereitstellen oder Senden von OFT-Dateien für Benutzer zum Öffnen

Sie können benutzerdefinierte Outlook-Formulare als OFT-Dateien speichern. Diese Formulare können benutzerdefinierte Felder, Änderungen an der Benutzeroberfläche und benutzerdefinierten VbScript-Code (Microsoft Visual Basic Scripting Edition) enthalten, um dem Formular Funktionen hinzuzufügen. Obwohl Outlook bereits Features enthält, die die Ausführung des VBScript-Codes in OFT-Dateien verhindern, schränkt Outlook jetzt auch die Verwendung von OFT-Dateien ein. Wenn eine OFT-Datei benutzerdefinierte Eigenschaften enthält und der Benutzer diese benutzerdefinierten Eigenschaften zuvor nicht verwendet hat, befinden sich die benutzerdefinierten Eigenschaften nicht im Standardspeicher des Benutzers. Outlook rendert das benutzerdefinierte Formular nicht, wenn der Benutzer auf die Datei doppelklicken. Wenn Outlook jedoch ein benutzerdefiniertes Formular öffnet, das als OFT-Datei gespeichert ist, klicken Sie auf Datei, dann auf Neu und dann auf Formular auswählen. Sie können dann den Speicherort in Benutzervorlagen im Dateisystem ändern und dann auf Durchsuchen klicken, um die OFT-Datei zu öffnen. Das Formular wird geöffnet, und Sie können die benutzerdefinierten Eigenschaften im Standardspeicher speichern.

Nicht empfohlen: Verwenden des Registrierungsschlüssels AllowNamedProps

Einige Organisationen haben möglicherweise triste Gründe, bestimmte benutzerdefinierte Eigenschaften im gesamten organization verfügbar zu haben. Wenn mehrere Speicher verwendet werden, sollten Sie sicherstellen, dass allen Speichern eine Reihe benutzerdefinierter Eigenschaften hinzugefügt werden können. Daher unterstützen Outlook 2003 SP2 und höhere Versionen clientseitige Registrierungsschlüssel, die angeben, welche benutzerdefinierten Eigenschaften erstellt werden können. Um anzugeben, welche benutzerdefinierten Eigenschaften aktiviert werden sollen, werden benutzerdefinierte Eigenschaften unter dem folgenden Registrierungsschlüssel definiert: HKEY_CURRENT_USER\Software\Microsoft\Office\<Version>\Outlook\AllowedNamedProps\

Hinweis In diesem Registrierungsschlüssel ist <Version> ein Platzhalter für die version von Outlook, die Sie verwenden. Für Outlook 2003 lautet die Versionsnummer 11.0. Für Outlook 2007 lautet die Versionsnummer 12.0. Die Versionsnummer wird in späteren Versionen von Outlook erhöht.

Die allgemeine Registrierungsschlüsselstruktur für einen Eintrag in der Registrierung sieht wie folgt aus:

<GUID ->

<Eigenschaftenname>

"Kind" (dword)

"ID" (dword)
"Type" (dword) Die folgenden Platzhalter werden in der Registrierungsschlüsselstruktur verwendet:

• <GUID>: Enthält die GUID, die den Eigenschaftensatz angibt. Benutzerdefinierte Outlook-Felder oder -Eigenschaften, die Sie in einem benutzerdefinierten Outlook-Formular verwenden, weisen alle die GUID {00020329-0000-0000-C000-0000000046} auf. In MAPI wird die GUID als PS_PULIC_STRINGS bezeichnet. Benutzerdefinierte MAPI-Programme verfügen jedoch möglicherweise über eigene GUIDs für benutzerdefinierte Eigenschaften.

• <Eigenschaftenname>: Gibt den Namen der Eigenschaft an. Wenn die Eigenschaft durch eine Zeichenfolge benannt wird, ist der <Eigenschaftenname> der tatsächliche Zeichenfolgenname der Eigenschaft. Wenn die Eigenschaft durch eine ID benannt wird, wird der Wert dieses Registrierungsschlüssels ignoriert. Sie müssen der Eigenschaft jedoch einen eindeutigen Namen geben, damit die Eigenschaft in der Registrierung gespeichert werden kann. Wenn der Kind-Schlüssel auf 1 oder <> 0 festgelegt ist, bestimmt der Name des Registrierungsschlüssels den Namen der Eigenschaft. Wenn der Kind-Schlüssel ungleich 1 ist, wird dieser Registrierungsschlüsselname ignoriert.

• "Kind" (dword): Gibt an, ob die Eigenschaft durch eine ID oder eine Zeichenfolge benannt wird. Wenn der Wert 0 ist, wird die Eigenschaft durch eine ID benannt. Der Name ist ein numerischer Wert, der durch eine ID angegeben wird. Wenn der Wert 1 ist, wird die Eigenschaft durch eine Zeichenfolge benannt. Diese Einstellung ist die Standardeinstellung, wenn "Kind" nicht vorhanden ist.

• "ID" (dword): Enthält den ID-Namen einer Eigenschaft, die durch eine ID benannt wird. Diese Informationen sind erforderlich, wenn der Kind-Schlüssel auf 0 festgelegt ist. Wenn der Schlüssel Kind auf 1 festgelegt ist, werden diese Informationen ignoriert.

• "Type" (dword): Gibt den Typ der Eigenschaft an.

Dieser Registrierungsschlüssel ist erforderlich, aber der Registrierungsschlüssel wird derzeit nicht verwendet. In der folgenden Tabelle sind die möglichen Werte dieses Registrierungsschlüssels basierend auf dem MAPI-Typ aufgeführt.

Im Folgenden finden Sie ein Beispiel für das Festlegen einer named-by-string-Eigenschaft:

Name: "MyStringFieldName1"

Typ: PT_LONG

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyStringFieldName1] "Type"=dword:00000003
Im Folgenden finden Sie ein Beispiel für das Festlegen einer named-by-ID-Eigenschaft:

ID: 0x0330

Typ: PT_LONG

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyMAPIProp1] "Kind"=dword:00000000 "ID"=dword:00000330 "Type"=dword:00000003


In diesen beiden Beispielen sieht die Registrierung in etwa wie folgt im Registrierungs-Editor aus:


{00020329-0000-0000-C000-00000000046}
 

MyStringFieldName1

Typ = 3
MyStringFieldName2

Typ = 3
{00020329-0000-0000-C000-00000000046}

MyMAPIProp1

Art = 0
ID = 330

Typ = 3
MyMAPIProp2

Art = 0
ID = 331
Typ = 3

Nicht empfohlen: Aktivieren Sie die Möglichkeit zum Erstellen von Eigenschaften erneut.

Drei Registrierungsschlüssel können auf Clientcomputern bereitgestellt werden, um das Blockieren benutzerdefinierter Eigenschaften zu deaktivieren und Outlook auf das vorherige Verhalten rückgängig machen. Diese Registrierungsschlüssel werden von Gruppenrichtlinien unterstützt. Die folgenden Registrierungsschlüssel können Outlook 2003 auf das vorherige Verhalten rückgängig machen:

Hinweis Die folgenden Registrierungsschlüssel rückgängig machen Outlook 2007 nicht auf das vorherige Verhalten.

• AllowTNEFtoCreateProps (HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] "AllowTNEFtoCreateProps"=dword:00000000): Wenn der Wert 0 ist, kann TNEF/MIME keine neuen benutzerdefinierten Eigenschaften von Outlook erstellen. Dieser Wert ist der Standardwert. Wenn der Wert 1 ist, kann TNEF/MIME neue benutzerdefinierte Eigenschaften erstellen, die Nicht-Outlook sind.

• AllowMSGFilestoCreateProps: Wenn der Wert 0 ist, können MSG-Dateien und OFT-Dateien keine neuen benutzerdefinierten Eigenschaften erstellen, die Nicht-Outlook sind. Dieser Wert ist der Standardwert. Wenn der Wert 1 ist, können MSG-Dateien und OFT-Dateien neue benutzerdefinierte Eigenschaften erstellen, die nicht in Outlook enthalten sind.

• Nicht zulassenTNEFPreservation: Um die Migration zu diesem neuen Verhalten zu vereinfachen, behält Outlook den ursprünglichen TNEF bei, wenn keine benutzerdefinierten Eigenschaften erstellt werden. Das ursprüngliche TNEF wird in einem binären Datenstrom für das element gespeichert, das gespeichert wird. Outlook verwendet das folgende Eigenschaftstag, um den Stream zu speichern:

  PR_TNEF_UNPROCESSED_PROPS PROG_TAG(PT_BINARY, 0x0e9C). Die HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] "DisallowTNEFPreservation "=dword:00000000
  die Registrierungseinstellung steuert, ob Outlook die PR_TNEF_UNPROCESSED_PROPS-Eigenschaft erstellt.
  
  Hinweis Die eigenschaft PR_TNEF_UNPROCESSED_PROPS wird aus einer Nachricht entfernt, wenn Sie eine Nachricht als Anlage in eine andere Nachricht einbetten. Die eigenschaft PR_TNEF_UNPROCESSED_PROPS wird auch entfernt, wenn Sie eine Nachricht weiterleiten oder auf eine Nachricht antworten.