2016-03-08 3 views
0

Je crée un complément Microsoft Outlook (Visual Studio 2012, C#, COM complémentaire, pas de VSTO, Outlook 2010/2013/2016), où 1) les utilisateurs doivent pouvoir composer et lire divers champs qui doivent être mappés vers/à partir des en-têtes MIME lorsque les messages quittent/entrent dans Microsoft Exchange, et 2) les champs doivent être disponibles en tant que champs Outlook natifs à utiliser par exemple comme colonnes dans les affichages Outlook, dans les expressions de recherche, etc.Zone de formulaire Outlook avec champ PS_INTERNET_HEADERS

Pour obtenir 1), les champs MAPI (Add-in Reads and Writes) dans l'espace de noms PS_INTERNET_HEADERS. Lorsque le complément est chargé pour la première fois, il crée un message caché fictif qui garantit qu'Exchange est forcé à effectuer le mappage entre les en-têtes MIME et les propriétés MAPI pour les messages entrants (résolution du problème décrit dans Named Properties, X-Headers, and You). Cela fonctionne bien.

Pour obtenir 2), je l'ai créé un formulaire Outlook à l'ancienne fichier de configuration (Creating a Form Configuration File) avec des entrées comme:

[Property.MMHSFoo] 
Type=31 
NmidPropset={00020386-0000-0000-C000-000000000046} 
NmidString=MMHS-Foo 
DisplayName=Foo 

Puis-je utiliser Redemption Outlook pour enregistrer le formulaire lorsque le complément des charges. Les utilisateurs peuvent maintenant utiliser le champ Foo comme autres champs Outlook.

Maintenant, mon problème est que lorsque j'utilise le concepteur de formulaire Outlook pour créer une région de formulaire, si j'essaie d'ajouter le champ Foo, j'obtiens une erreur disant "L'opération a échoué". Si je change la valeur NmidPropset de PS_INTERNET_HEADERS (00020386-0000-0000-C000-000000000046) en PS_PUBLIC_STRINGS (00020329-0000-0000-C000-000000000046), je peux ajouter le champ Foo, mais 1) ne fonctionne pas.

Donc ma question est: comment puis-je ajouter des champs de l'espace de noms PS_INTERNET_HEADERS à une région de formulaire Outlook de sorte que les exigences 1) et 2) sont remplies?

Répondre

0

Tout d'abord, pour (1), vous n'avez pas besoin de créer de messages - appelez simplement GetIDsFromNames (... MAPI_CREATE) sur n'importe quel objet de stockage (IMsgStore, IMAPIFolder, IMessage, etc.).

Pour (2), je ne pense pas que le formulaire fonctionnera avec autre chose que PS_PUBLIC_STRINGS. Pourquoi ne pas créer un volet des tâches et remplir son contenu explicitement dans votre code?

+0

J'ai créé un volet de tâches personnalisé pour cette raison. Une chose que je n'ai pas mentionnée était que je voulais aussi que mes propriétés apparaissent quand les messages sont imprimés. Les propriétés d'un formulaire sont imprimées, mais les propriétés de PS_INTERNET_HEADERS ne sont pas imprimées. Aucun conseil? –

+0

Les propriétés doivent être dans la collection UserProperties pour être imprimables. –

+0

Dans le contexte d'une fenêtre d'inspecteur, j'utilise la collection UserProperties pour définir un objet UserProperty. Si je choisis ensuite d'imprimer le message, la modification de cette propriété UserProperty n'est pas incluse dans l'impression. Mais si je ferme le message et le rouvre, le changement est inclus. Le code est similaire à 'mailItem.UserProperties.Add ("Foo", Outlook.OlUserPropertyType.olText, false)'. D'un autre côté, si j'utilise OutlookSpy pour effectuer la même modification, la modification est immédiatement répercutée, c'est-à-dire que l'impression inclut le changement sans avoir à rouvrir le message. Qu'est-ce que OutlookSpy fait différemment? –