Modifications apportées aux propriétés personnalisées dans Outlook

Bonne pratique : Ajouter des champs personnalisés par programmation

Différentes API peuvent être utilisées pour ajouter par programmation des champs personnalisés aux éléments. Pour ce faire, utilisez la méthode UserProperties.Add dans la bibliothèque d’objets Outlook (« Outlook.Application »). Le code suivant illustre cette bonne pratique.

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

Vous pouvez également utiliser la bibliothèque d’objets CDO (« MAPI. Session « ) pour ajouter des champs personnalisés. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :

http://msdn2.microsoft.com/en-us/library/ms527518.aspx Pour les développeurs C++, mapI étendu peut être utilisé pour ajouter des propriétés nommées. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :

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

Bonne pratique : utiliser des formulaires personnalisés publiés qui contiennent des champs personnalisés

Outlook approuve en grande partie les formulaires personnalisés publiés. Toutefois, Outlook n’approuve pas les formulaires non publiés ou les formulaires ponctuels. Cela inclut les fichiers .oft. Par conséquent, lorsque vous concevez une solution de formulaire personnalisé, nous vous recommandons vivement de publier le formulaire personnalisé. Vous devez concevoir le formulaire afin qu’il ne devienne pas un formulaire unique. Tant qu’un formulaire est publié, le formulaire n’est pas affecté par la modification dans Outlook.
 
Lorsque vous publiez un fichier .oft dans un autre magasin, le magasin par défaut vous permet de créer des propriétés dans ce magasin. En outre, lorsque vous créez un formulaire personnalisé qui a des propriétés personnalisées et que vous le publiez dans la bibliothèque ou le dossier de formulaires approprié, les propriétés personnalisées sont créées dans les magasins affectés.

Bonne pratique : déploiement par programmation de formulaires personnalisés

Si vous développez un formulaire personnalisé Outlook qui sera utilisé par d’autres personnes, vous pouvez utiliser peu d’approches. L’approche que vous utilisez dépend de plusieurs facteurs. Ces facteurs incluent le type de formulaire, qui utilisera le formulaire, où le formulaire sera utilisé, et ainsi de suite. En règle générale, si un formulaire personnalisé est utilisé par de nombreuses personnes, nous vous recommandons de publier le formulaire dans la bibliothèque de formulaires d’organisation. Toutefois, si ce n’est pas possible, vous pouvez publier le formulaire dans un dossier partagé ou dans la bibliothèque de formulaires personnels de certains utilisateurs. Vous pouvez installer par programmation un formulaire personnalisé à l’aide de la méthode CreateItemFromTemplate dans la bibliothèque d’objets Outlook. Vous utilisez la méthode CreateItemFromTemplate pour ouvrir un fichier .oft, puis vous publiez le formulaire à l’aide de la méthode PublishForm. Dans ce cas, un fichier .oft n’est pas affecté par les modifications des propriétés personnalisées.

Non recommandé : déployer ou envoyer des fichiers .oft pour les utilisateurs à ouvrir

Vous pouvez enregistrer des formulaires personnalisés Outlook en tant que fichiers .oft. Ces formulaires peuvent contenir des champs personnalisés, des modifications d’interface utilisateur et du code Microsoft Visual Basic Scripting Edition (VBScript) personnalisé pour ajouter des fonctionnalités au formulaire. Bien qu’Outlook contienne déjà des fonctionnalités qui empêchent l’exécution du code VBScript dans les fichiers .oft, Outlook limite désormais également l’utilisation des fichiers .oft. Si un fichier .oft contient des propriétés personnalisées et que l’utilisateur n’a pas déjà utilisé ces propriétés personnalisées, les propriétés personnalisées ne se trouvent pas dans le magasin par défaut de l’utilisateur. Outlook ne restitue pas le formulaire personnalisé lorsque l’utilisateur double-clique sur le fichier. Toutefois, pour qu’Outlook ouvre un formulaire personnalisé stocké sous la forme d’un fichier .oft, cliquez sur Fichier, sur Nouveau, puis sur Choisir un formulaire. Vous pouvez ensuite remplacer l’emplacement par Modèles utilisateur dans le système de fichiers, puis cliquer sur Parcourir pour ouvrir le fichier .oft. Le formulaire s’ouvre et vous pouvez enregistrer les propriétés personnalisées dans le magasin par défaut.

Non recommandé : utiliser la clé de Registre AllowNamedProps

Certaines organisations peuvent avoir des raisons valables de disposer de certaines propriétés personnalisées tout au long de la organization. Si plusieurs magasins sont utilisés, vous pouvez vous assurer qu’un ensemble de propriétés personnalisées peut être ajouté à tous les magasins. Par conséquent, Outlook 2003 SP2 et les versions ultérieures prennent en charge les clés de Registre côté client qui spécifient les propriétés personnalisées qui peuvent être créées. Pour spécifier les propriétés personnalisées qui doivent être activées, les propriétés personnalisées sont définies sous la clé de Registre suivante : HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\AllowedNamedProps\

Remarque Dans cette clé de Registre, <version> est un espace réservé pour la version d’Outlook que vous utilisez. Pour Outlook 2003, le numéro de version est 11.0. Pour Outlook 2007, le numéro de version est 12.0. Le numéro de version augmentera dans les versions ultérieures d’Outlook.

La structure de clé de Registre globale pour une entrée dans le Registre est la suivante :

> GUID <

> nom de la propriété <

« Kind » (dword)

« ID » (dword)
« Type » (dword) Les espaces réservés suivants sont utilisés dans la structure de clé de Registre :

• <GUID> : contient le GUID qui spécifie le jeu de propriétés. Les champs personnalisés Outlook, ou propriétés, que vous utilisez sur un formulaire personnalisé Outlook ont tous le GUID {00020329-0000-0000-C000-000000000000046}. Dans MAPI, le GUID est appelé PS_PULIC_STRINGS. Toutefois, les programmes MAPI personnalisés peuvent avoir leurs propres GUID pour les propriétés personnalisées.

• <nom de la propriété> : spécifie le nom de la propriété. Si la propriété est nommée par une chaîne, la <Nom de la propriété> est le nom de chaîne réel de la propriété. Si la propriété est nommée par un ID, la valeur de cette clé de Registre est ignorée. Toutefois, vous devez donner un nom unique à la propriété afin qu’elle puisse être stockée dans le registre. Si la clé Kind a la valeur 1 ou est <> 0, le nom de la clé de Registre détermine le nom de la propriété. Si la clé Kind n’est pas égale à 1, ce nom de clé de Registre est ignoré.

• « Kind » (dword) : spécifie si la propriété est nommée par un ID ou par une chaîne. Si la valeur est 0, la propriété est nommée par un ID. Le nom est une valeur numérique spécifiée par un ID. Si la valeur est 1, la propriété est nommée par une chaîne. Ce paramètre est le paramètre par défaut lorsque « Kind » n’est pas présent.

• « ID » (dword) : contient le nom d’ID d’une propriété nommée par un ID. Ces informations sont requises si la clé kind est définie sur 0. Si la clé Kind est définie sur 1, ces informations sont ignorées.

• « Type » (dword) : spécifie le type de propriété.

Cette clé de Registre est obligatoire, mais la clé de Registre n’est pas utilisée actuellement. Le tableau suivant répertorie les valeurs possibles de cette clé de Registre en fonction du type MAPI.

Voici un exemple de définition d’une propriété nommée par chaîne :

Nom : « MyStringFieldName1 »

Type : PT_LONG

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyStringFieldName1] « Type"=dword:00000003
Voici un exemple de définition d’une propriété nommée par ID :

ID : 0x0330

Type : 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


Pour ces deux exemples, le registre ressemble à ce qui suit dans l’Éditeur du Registre :


{00020329-0000-0000-C000-000000000046}
 

MyStringFieldName1

Type = 3
MyStringFieldName2

Type = 3
{00020329-0000-0000-C000-000000000046}

MyMAPIProp1

Type = 0
ID = 330

Type = 3
MyMAPIProp2

Type = 0
ID = 331
Type = 3

Non recommandé : réactivez la possibilité de créer des propriétés

Trois clés de Registre peuvent être déployées sur les ordinateurs clients pour désactiver le blocage des propriétés personnalisées et rétablir le comportement précédent d’Outlook. Ces clés de Registre sont prises en charge par les stratégies de groupe. Les clés de Registre suivantes peuvent rétablir le comportement précédent d’Outlook 2003 :

Remarque Les clés de Registre suivantes ne rétablissent pas outlook 2007 à son comportement précédent.

• AllowTNEFtoCreateProps (HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] « AllowTNEFtoCreateProps"=dword:00000000) : si la valeur est 0, TNEF/MIME ne peut pas créer de propriétés personnalisées non Outlook. Cette valeur est la valeur par défaut. Si la valeur est 1, TNEF/MIME peut créer des propriétés personnalisées non Outlook.

• AllowMSGFilestoCreateProps : si la valeur est 0, les fichiers .msg et .oft ne peuvent pas créer de propriétés personnalisées autres qu’Outlook. Cette valeur est la valeur par défaut. Si la valeur est 1, les fichiers .msg et .oft peuvent créer des propriétés personnalisées non Outlook.

• DisallowTNEFPreservation : pour faciliter la migration vers ce nouveau comportement, Outlook conserve le TNEF d’origine lorsque les propriétés personnalisées ne sont pas créées. Le TNEF d’origine est enregistré dans un flux binaire sur l’élément enregistré. Outlook utilise la balise de propriété suivante pour enregistrer le flux :

  PR_TNEF_UNPROCESSED_PROPS PROG_TAG(PT_BINARY, 0x0e9C). The HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] « DisallowTNEFPreservation « =dword:0000000000
  Le paramètre de registre contrôle si Outlook crée la propriété PR_TNEF_UNPROCESSED_PROPS.
  
  Remarque La propriété PR_TNEF_UNPROCESSED_PROPS est supprimée d’un message lorsque vous incorporez un message dans un autre message en tant que pièce jointe. La propriété PR_TNEF_UNPROCESSED_PROPS est également supprimée lorsque vous transférez un message ou répondez à un message.