locked
COM Outlook addin ribbon buttons not responding in Korean Outlook 2010 RRS feed

  • Question

  • Hi Folks,

    I have a COM Outlook addin which implements a ribbon button in Outlook 2010. It's been working just fine for quite some time. Until someone tried to load the addin in the Korean version of Outlook. The ribbon buttons show up but do not do anything when clicked.  In the debugger, I see the error message below whenever I click on the ribbon button "ERROR : Unable to load Typelibrary. (HRESULT = 0x8002801d)
     Verify TypelibID and major version specified with
     IDispatchImpl, CStockPropImpl, IProvideClassInfoImpl or IProvideCLassInfo2Impl".

    I never hit my break point in the callback for this button, so something is going on in the event layer above my code I think. But I don't know what and I don't know why using the Korean version of Outlook should make any different. Anyone have any ideas?

    (Sice this addin has been around awhile, it also has command bars and buttons to do the same thing. These still work (though they're shunted to the addins tab))

     


    Anonymous6
    Wednesday, October 27, 2010 7:51 PM

Answers

  • The typelib lookup it is failing on is the COM addin's own typelib. ProcMon shows Korean Outlook trying to get the typelib from HKCR and failing. There's no reason why it should fail, I can see the registration clearly in regedit under the HKCR key.

    As I said before, my addin is installed for current user, so all registrations get done under "HKCU\Software\Classes".

    When I hack in a registry entry for my typelib under "HKLM\Software\Classes", suddenly Korean Outlook finds everything fine and the addin works. 

    When the addin starts up, I'm just going to have it create the typelib entry under HKLM. It's a hack, but I don't know what the heck MS is having Outlook do in Korean (possibly other languages?) when looking up entries in HKCR.

     


    Anonymous6
    Thursday, November 4, 2010 2:50 PM

All replies

  • I'm thinking it has something to do with the LIBID_Office macro used below when defining the interfaces my main addin supports:

        , public IDispatchImpl<IRibbonExtensibility, &__uuidof(IRibbonExtensibility), &LIBID_Office, /* wMajor = */ 2, /* wMinor = */ 4>

    The macro is defined as extern "C" const GUID __declspec(selectany) LIBID_Office =
        {0x2df8d04c,0x5bfa,0x101b,{0xbd,0xe5,0x00,0xaa,0x00,0x44,0xde,0x52}};


    Anonymous6
    Thursday, October 28, 2010 12:54 PM
  • We just saw this issue with the CRM add-in on some boxes. Check the registry on the box. If the 2.4 subkey is beneath the typelib guid reg key (HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}), delete it. You should only have the 2.5 subkey on the box if 2010 is installed.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Patrick Microsoft Online Community Support
    Thursday, October 28, 2010 4:00 PM
  • I just have a 2.5 entry on the Korean Outlook machine with the ribbon button problem.

    My English Outlook machine has both 2.4 and 2.5 entries.  I am specifically coding for 2.4 for some reason. I will play around a little with the versions.

    Helpful information. Thankyou.


    Anonymous6
    Thursday, October 28, 2010 5:17 PM
  • You should use ProcMon to see where Outlook is looking in the registry to figure out the typelib to use. It will be useful in your troubleshooting.

    If you decide you need further support on this, then please consider opening a support case with us so we can investigate it with you.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Patrick Microsoft Online Community Support
    Thursday, October 28, 2010 6:24 PM
  • Oddly, if I register my addin with regsvr32, everything works fine in Korean. regsvr32 is registering things to HKLM. My own installer registers the classes to HKCU. But when I do that, for some reason the type library isn't being found. ERROR : Unable to load Typelibrary. (HRESULT = 0x8002801d) Verify TypelibID and major version specified with IDispatchImpl, CStockPropImpl, IProvideClassInfoImpl or IProvideCLassInfo2Impl
    Anonymous6
    Wednesday, November 3, 2010 1:59 PM
  • The typelib lookup it is failing on is the COM addin's own typelib. ProcMon shows Korean Outlook trying to get the typelib from HKCR and failing. There's no reason why it should fail, I can see the registration clearly in regedit under the HKCR key.

    As I said before, my addin is installed for current user, so all registrations get done under "HKCU\Software\Classes".

    When I hack in a registry entry for my typelib under "HKLM\Software\Classes", suddenly Korean Outlook finds everything fine and the addin works. 

    When the addin starts up, I'm just going to have it create the typelib entry under HKLM. It's a hack, but I don't know what the heck MS is having Outlook do in Korean (possibly other languages?) when looking up entries in HKCR.

     


    Anonymous6
    Thursday, November 4, 2010 2:50 PM