I am creating a Microsoft Outlook add-in (Visual Studio 2012, C#, COM add-in, no VSTO, Outlook 2010/2013/2016), where 1) users must be able to compose and read various fields that must be mapped to/from MIME headers when messages leave/enter Microsoft Exchange, and 2) the fields must be available as native Outlook fields to be used e.g. as columns in Outlook views, in search expressions, etc.
To obtain 1), the add-in reads and writes (MAPI) fields in the PS_INTERNET_HEADERS namespace. When the add-in is first loaded, it creates a dummy hidden message that ensures that Exchange is forced to do the mapping between MIME headers and MAPI properties for incoming messages (addressing the problem described in Named Properties, X-Headers, and You). That works fine.
To obtain 2), I have created an old-fashioned Outlook Form Configuration File (Creating a Form Configuration File) with entries like:
[Property.MMHSFoo]
Type=31
NmidPropset={00020386-0000-0000-C000-000000000046}
NmidString=MMHS-Foo
DisplayName=Foo
Then I use Outlook Redemption to register the form when the add-in loads. Now users can use field Foo as other Outlook fields.
Now, my problem is that when I use the Outlook form designer to create a form region, if I try to add field Foo, I get an error saying ‘The operation failed’. If I change the NmidPropset value from PS_INTERNET_HEADERS (00020386-0000-0000-C000-000000000046) to PS_PUBLIC_STRINGS (00020329-0000-0000-C000-000000000046), I can add field Foo, but then 1) does not work.
Thus my question is: how can I add fields from namespace PS_INTERNET_HEADERS to an Outlook form region such that both requirement 1) and 2) are fulfilled?
Firstly, for (1), you don't need to create any messages - just call GetIDsFromNames(...MAPI_CREATE) on any store object (IMsgStore, IMAPIFolder, IMessage, etc.).
For (2), I don't think the form will work with anything but PS_PUBLIC_STRINGS. Why not create a task pane and populate its contents explicitly in your code?