none
Using WebBrowser control in Outlook 2013 - killbit RRS feed

  • Question

  • Hi All,

    I have a c++ add-in that uses WebBrowser control to display local HTML content and to display OpenID/OAuth dialogs. It works great for Outlook 2007/2010. The problem is that Outlook 2013 (and Office 2013 in general) blocks WebBrowser controls from being initiated via killbits. See http://support.microsoft.com/kb/2793374

    I know that I can remove the killbit but it's not reasonable to expect our users to manually edit the registry.Any recommendation for a replacement that is not blocked?

    Thanks much,
    Slavik

    Wednesday, March 5, 2014 2:34 AM

Answers

  • Ken, Eugene, thanks for the answers. Eventually, it seems that the solution is rather simple. You can create an ATL DHTML Control and use it within Outlook (Office) 2013. It seems that if the browser control is wrapped in your own control it is enough not to trigger the killbit.

    Thanks,
    Slavik

    • Marked as answer by SlavikM Thursday, March 13, 2014 9:32 PM
    Thursday, March 13, 2014 9:20 PM

All replies

  • Hello Slavik,

    I'd recommend move your code to the Outlook Form Regions or/and Adjacent Windows In Outlook for displaying the content without a web browser control.

    Wednesday, March 5, 2014 11:51 AM
  • Hi Eugene, thanks for the reply.

    My content is HTML and it sometimes comes from the web. The most convenient way to do so would be the web browser control. Is there a way maybe for me to wrap the control to bypass the killbit setting?

    Thanks a lot,
    Slavik

    Wednesday, March 5, 2014 5:17 PM
  • Hi Slavik,

    Unfortunately I don't know any possible workaround to wrap a control for bypassing the killbit settings.

    Wednesday, March 5, 2014 8:20 PM
  • Eugene - do you think I can use the word.document control instead of the web browser control to display HTML content?

    I have the following code (removed error handling):

    *ppTaskPane = NULL;
    CLSID clsid;
    ::CLSIDFromProgID(L"Word.document",&clsid);
    LPOLESTR lpolestr;
    StringFromCLSID(clsid, &lpolestr);
    pCTPFactoryInst->CreateCTP(lpolestr, CComBSTR(L"Custom content"), parent, ppTaskPane);
    CComPtr<IDispatch> spDocument;
    (*ppTaskPane)->get_ContentControl(&spDocument);
    CComPtr<Word::_Document> spDoc;
    spDocument->QueryInterface<Word::_Document>(&spDoc);
    CComPtr<Word::Range> spContent;
    spDoc->get_Content(&spContent);
    spContent->Select();
    CComBSTR newBody(msg.getBody().c_str());
    spContent->put_Text(newBody);
    (*ppTaskPane)->put_DockPosition(msoCTPDockPositionBottom);
    hr = (*ppTaskPane)->put_Visible(TRUE);
    

    Everything runs but I do not see my content displayed in the CTP. Since I'm far from being an expert, there are probably numerous things I'm missing - but I'd be happy to receive some pointers.

    PS - the same code with the web browser control (of course, content is placed differently) works without issue.

    Thanks,
    Slavik

    Thursday, March 6, 2014 7:32 AM
  • Hi Slavik,

    Typically, Outlook 2007+ uses Word for displaying the body of Outlook items by default. But it has some limitations too.

    The WordEditor property of the Inspector class provides access to the Document class from the Word object model which represents the body. The WordEditor property is only valid if the IsWordMail method returns True (actually, it will always be true in case of Outlook 2007+) and the EditorType property is olEditorWord.


    Thursday, March 6, 2014 1:11 PM
  • Hi Eugene, thanks. Yes, I know about the WordEditor and use it in places where relevant in my add-in but here I'm doing something else. I'm creating a custom task pane and using a stand-alone instance of the word.document to display content there. Any idea what I'm doing wrong?
    Thursday, March 6, 2014 5:10 PM
  • Hi Slavik,

    Based on the code snippet listed above, I understand what you are trying to achieve. I have never tried to implement such scenario in add-ins. 

    Moreover, creating Word documents is not a good idea due to the fact that any Document instance is received from Word Application's properties and methods (not created directly using ctor).

    Thursday, March 6, 2014 5:23 PM
  • The CTP would be running under the Outlook process, as would be your addin. The Word document would be running under a different process and thread, that wouldn't mix very well.

    Could you create the document you want in a dummy Outlook mailitem stored in some other folder and then display that item in your CTP? That should work.

    One thing to bear in mind is that you'd have a subset of Word, and due to various limitations not all HTML type formatting and codes would work. What you did would have to be acceptable as Outlook HTML.


    Ken Slovak MVP - Outlook

    Friday, March 7, 2014 4:42 PM
    Moderator
  • Ken, Eugene, thanks for the answers. Eventually, it seems that the solution is rather simple. You can create an ATL DHTML Control and use it within Outlook (Office) 2013. It seems that if the browser control is wrapped in your own control it is enough not to trigger the killbit.

    Thanks,
    Slavik

    • Marked as answer by SlavikM Thursday, March 13, 2014 9:32 PM
    Thursday, March 13, 2014 9:20 PM
  • Hi Slavik,

    Thank you for sharing the solution for other forum readers.

    Thursday, March 13, 2014 9:29 PM