Form Region replace-all RRS feed

  • Question

  • Hi All,

    I have created an OFS file to replace the "default" contact form (replace-all). I am registering it from a COM addin. I think that I do not have the proper entries for the manifest file because my form region is not replacing the default contact form. It does show up as an icon on the ribbon and it does show when I click the icon. So I cannot help but think that I have a wrong entry in my manifest file or I am not registering form correctly.

    All of the examples I have seen on the web only reference adjoining or seperate. Is there any documentation that will show the correct way to register a form region for replace and replace-all.

    BTW - I see conflicting entries in numerous places for the correct entry for the formRegionType entry in the manifest file. Some MSDN pages specify "replaceall" and some MSDN pages specify "replace-all". I believe the correct entry is "replace-all" since nothing shows up for the other.

    This is my current manifest

    <?xml version="1.0" encoding="utf-8" ?>
    <FormRegion xmlns="">
        <title>My Awesome Contact Form</title>




    Friday, January 27, 2012 11:19 PM

All replies

  • Hi Tom,

    We are doing some researches on this case now, which might take some time before we can post back here.

    Thanks for your understanding and patient.

    Good day,

    Calvin Gao[MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 30, 2012 7:31 AM
  • Thanks! I meant to write you yesterday, but time got away on me. We are looking forward to some insight regarding this issue.

    Tuesday, January 31, 2012 2:55 PM
  • Hi Tom,

    The <formRegionType> should be set to "replaceAll" (without the quotes) in the manifest.

    However, when you use a replace or replaceAll form region, it can only be used on items with a custom message class. This is mentioned here:

    In particular: "You can use a replacement form region to replace the default page of a standard form, or a replace-all form region to replace the entire standard form. In this case, you must specify a derived message class for the form region and register the form region for that message class."

    This may present some logistical concerns depending on your scenario. Your add-in will probably need to change the default form (message class) for the contact folder, and that you can do with PropertyAccessor. There's a code sample here:

    Also, you would likely need to update the existing items to the new message class, but when deploying, of course you would need to take into account that the contact folder may already be set up to use another custom form. So you would need to decide how to handle that potential scenario.

    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging
    Tuesday, January 31, 2012 4:22 PM
  • Thanks for you answer.  I think I can handle that. I do have some additional questions.

    1. What are the required manifest elements for "replaceAll"? I have not found a document.

    2. If I follow your instructions will I still have the theme? Please confirm that I will not lose the theme like you would with a custom form.

    3. I was defining my default message class as "IPM.Contact.jal". Do I have to do something else in my add-in to force the form to be default?


    Tuesday, January 31, 2012 4:32 PM
  • Hmmm? if I change my form region type to "replaceAll" from "replace-all" my "GetFormRegionStorage" method is never called. So I do not think that replaceAll entry works OR there is another value in the manifest file that I do not know about. Never the less something is definitely missing from the documention regarding this region type.


    Tuesday, January 31, 2012 6:00 PM
  • Hi Tom,

    Sorry, I know the form region documentation can be somewhat confusing since it's a bit scattered and written from multiple perspectives. It sounds like you are likely going through the VSTO-based documentation. However, the core documentation is published under Outlook in MSDN, so here's a link to the primary page you are looking for (I'm assuming you haven't seen this already):

    You don't necessarily need VSTO or an add-in to create a form region, so the Outlook documentation covers all of the architectural aspects of form regions in a rather generic way since it's possible to manually create and register everything using just Outlook. I would suggest reading through that first, and then the VSTO documentation basically adds to those concepts in terms of how VSTO can be used to streamline form region development and add the business logic via custom code.

    There are very few manifest elements that are actually required, and those should be pretty intuitive. If any are omitted, Outlook just uses their default values. It's usually pretty straightforward in terms of specifiying those elements that are applicable to your situation. You shouldn't really need anything special to get this form region to render. Assuming the registry entries are there, the XML file is correct, and the item that is being opened (new or existing item) is using a custom message class, the form region should display. While VSTO would be handling the registry keys for you with regard to the custom message class, they are also documented here:

    Also, yes, one of the benefits of form regions is support for theming, which legacy Outlook forms lack. Regardless of how they are implemeneted the Visual Studio (WinForm) or Outlook 2007/2010 controls (.ofs) will render in themed UI. FWIW, while I'm not sure of your UI requirements, in most scenarios, I would really recommend using the .ofs file so that you can use the Outlook controls since they were specifically designed to replicate the default controls that Outlook uses. Deciding WinForm vs. the OFS approach is an important decision since you can't mix and match controls and form surfaces.

    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging
    Tuesday, January 31, 2012 10:47 PM
  • Okay ... I will look at the docs tomorrow morning.

    FYI - I am creating an ATL COM addin. This add-in supports 2003 and 2002 with a custom form. But for 2007 and above I want to use a form region and a replaceAll which seems not to be cooperating.

    FYI 2 - I have done many many form regions..but never a replaceAll or replace. Seems like the behavior is quite different and so far not behaving as advertised.

    Tuesday, January 31, 2012 10:54 PM
  • Hi Tom,

    Thanks for clarifying my wrong assumptions! Overall, there really shouldn't much difference with a Replace/ReplaceAll form regions other than the need for a custom message class. Unfortunately if you are integrating with a user's default Contacts folder, that can get logistically painful since you'd need to ensure all items in the folder have the custom message class.

    Now that I think about it more, perhaps another avenue to persue would be to use a separate form region to avoid the need for a custom message class, and then use HideFormPage to hide the default pages (and/or pages from your legacy custom form). Offhand I'm not sure if that would work in the grand scheme of things, but just something you may want to consider.

    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging
    Thursday, February 2, 2012 4:23 PM
  • The default send email dialog will not work in my case.

    1) The requirement is not to actually send the message, but we are thinking posting the message to an external web service that will use a third party CRM product to target users.

    2) the TO box needs to be replaced with target users and email lists pulled from an external system

    3) I need a custom task pane, or equivalent. 

    4) I need the editing to be using the same control that outlook uses.

    Is there a way to build a custom form launched off of explorer ribbon that can do this? I am wondering how I could leverage the internal word editor that is built into outlook in this form.  I am using VSTO 2010 to do all work. 

    The email client is version 2010.

    Thursday, September 29, 2016 3:11 PM