[This is now documented here: http://msdn.microsoft.com/en-us/library/bb820993.aspx]
There's a KB article (http://support.microsoft.com/kb/229700) that discusses how to use FGetComponentPath to find MAPISVC.INF. It has two major problems:
The code below corrects both problems. Here's why:
Non-English
I'll admit - I never fully understood this before. The documentation for FGetComponentPath indicates the szQualifier should be "(t)he MSIApplicationLCID or MSIOfficeLCID subkey described in Setting Up the MSI Keys for Your MAPI DLL." I must have skimmed over that comment hundreds of times before it sunk in. It means to go get those keys and pass what's in them to FGetComponentPath! This will allow FGetComponentPath to use the data in those keys to help locate where the localized copy of the component (MAPI) was installed. If szQualifier is left out, it will try to find the installed component using the system's default user LCID, then the system's default LCID, then a hard coded value of 1033 (English-US). This is why the code in the article would work in English locales but not elsewhere.
Outlook 2007
Here, again, it pays to read the documentation for FGetComponentPath (something I'm guilty of not doing). It says szComponent should be "(t)he MSIComponentID reg key described in Mapi32.dll Stub Registry Settings." The code in the article ignored this and instead passed "{473FF9A0-D659-11D1-A4B2-006008AF820E}", which was the component ID of MAPISVC.INF on Outlook 2000. This worked fine when the article was written, and continued to work up through Outlook 2003. However, Outlook 2007 no longer installs MAPISVC.INF (though it will use it if it finds it), so this component ID stops working. The fix is to pass "{FF1D0740-D227-11D1-A4B0-006008AF820E}", which is the component ID of MAPI that you'd get if you read the MSIComponentID key. In the code below, I hard coded this ID, but it would be better to try and read it from the registry first and only fall back to the hard coded string on failure.
This code should work with all versions of Outlook, but I've only tested it with Outlook 2003 and 2007.
// HrGetRegMultiSZValueA // Get a REG_MULTI_SZ registry value - allocating memory using new to hold it. void HrGetRegMultiSZValueA( IN HKEY hKey, // the key. IN LPCSTR lpszValue, // value name in key. OUT LPVOID* lppData) // where to put the data. { *lppData = NULL; DWORD dwKeyType = NULL; DWORD cb = NULL; LONG lRet = 0; // Get its size lRet = RegQueryValueExA( hKey, lpszValue, NULL, &dwKeyType, NULL, &cb); if (ERROR_SUCCESS == lRet && cb && REG_MULTI_SZ == dwKeyType) { *lppData = new BYTE[cb]; if (*lppData) { // Get the current value lRet = RegQueryValueExA( hKey, lpszValue, NULL, &dwKeyType, (unsigned char*)*lppData, &cb); if (ERROR_SUCCESS != lRet) { delete[] *lppData; *lppData = NULL; } } } } typedef BOOL (STDAPICALLTYPE FGETCOMPONENTPATH) (LPSTR szComponent, LPSTR szQualifier, LPSTR szDllPath, DWORD cchBufferSize, BOOL fInstall); typedef FGETCOMPONENTPATH FAR * LPFGETCOMPONENTPATH; /////////////////////////////////////////////////////////////////////////////// // Function name : GetMAPISVCPath // Description : This will get the correct path to the MAPISVC.INF file. // Return type : void // Argument : LPSTR szMAPIDir - Buffer to hold the path to the MAPISVC file. // ULONG cchMAPIDir - size of the buffer void GetMAPISVCPath(LPSTR szMAPIDir, ULONG cchMAPIDir) { HRESULT hRes = S_OK; UINT uiRet = 0; LONG lRet = 0; BOOL bRet = true; szMAPIDir[0] = '\0'; // Terminate String at pos 0 (safer if we fail below) CHAR szSystemDir[MAX_PATH+1] = {0}; // Get the system directory path // (mapistub.dll and mapi32.dll reside here) uiRet = GetSystemDirectoryA(szSystemDir, MAX_PATH); if (uiRet > 0) { CHAR szDLLPath[MAX_PATH+1] = {0}; hRes = StringCchPrintfA(szDLLPath, MAX_PATH+1, "%s\\%s", szSystemDir, "mapistub.dll"); if (SUCCEEDED(hRes)) { LPFGETCOMPONENTPATH pfnFGetComponentPath = NULL; HMODULE hmodStub = 0; HMODULE hmodMapi32 = 0; // Load mapistub.dll hmodStub = LoadLibraryA(szDLLPath); if (hmodStub) { // Get the address of FGetComponentPath from the mapistub pfnFGetComponentPath = (LPFGETCOMPONENTPATH)GetProcAddress( hmodStub, "FGetComponentPath"); } // If we didn't get the address of FGetComponentPath // try mapi32.dll if (!pfnFGetComponentPath) { hRes = StringCchPrintfA(szDLLPath, MAX_PATH+1, "%s\\%s", szSystemDir, "mapi32.dll"); if (SUCCEEDED(hRes)) { // Load mapi32.dll hmodMapi32 = LoadLibraryA(szDLLPath); if (hmodMapi32) { // Get the address of FGetComponentPath from mapi32 pfnFGetComponentPath = (LPFGETCOMPONENTPATH)GetProcAddress( hmodMapi32, "FGetComponentPath"); } } } if (pfnFGetComponentPath) { LPSTR szAppLCID = NULL; LPSTR szOfficeLCID = NULL; HKEY hMicrosoftOutlook = NULL; lRet = RegOpenKeyEx( HKEY_LOCAL_MACHINE, _T("Software\\Clients\\Mail\\Microsoft Outlook"), NULL, KEY_READ, &hMicrosoftOutlook); if (ERROR_SUCCESS == lRet && hMicrosoftOutlook) { HrGetRegMultiSZValueA(hMicrosoftOutlook, "MSIApplicationLCID", (LPVOID*) &szAppLCID); HrGetRegMultiSZValueA(hMicrosoftOutlook, "MSIOfficeLCID", (LPVOID*) &szOfficeLCID); } if (szAppLCID) { bRet = pfnFGetComponentPath( "{FF1D0740-D227-11D1-A4B0-006008AF820E}", szAppLCID, szMAPIDir, cchMAPIDir, true); } if ((!bRet || szMAPIDir[0] == _T('\0')) && szOfficeLCID) { bRet = pfnFGetComponentPath( "{FF1D0740-D227-11D1-A4B0-006008AF820E}", szOfficeLCID, szMAPIDir, cchMAPIDir, true); } if (!bRet || szMAPIDir[0] == _T('\0')) { bRet = pfnFGetComponentPath( "{FF1D0740-D227-11D1-A4B0-006008AF820E}", NULL, szMAPIDir, cchMAPIDir, true); } // We got the path to msmapi32.dll - need to strip it if (bRet && szMAPIDir[0] != _T('\0')) { LPSTR lpszSlash = NULL; LPSTR lpszCur = szMAPIDir; for (lpszSlash = lpszCur; *lpszCur; lpszCur = lpszCur++) { if (*lpszCur == _T('\\')) lpszSlash = lpszCur; } *lpszSlash = _T('\0'); } delete[] szOfficeLCID; delete[] szAppLCID; if (hMicrosoftOutlook) RegCloseKey(hMicrosoftOutlook); } // If FGetComponentPath returns FALSE or if // it returned nothing, or if we never found an // address of FGetComponentPath, then // just default to the system directory if (!bRet || szMAPIDir[0] == '\0') { hRes = StringCchPrintfA( szMAPIDir, cchMAPIDir,"%s", szSystemDir); } if (szMAPIDir[0] != _T('\0')) { hRes = StringCchPrintfA( szMAPIDir, cchMAPIDir, "%s\\%s", szMAPIDir, "MAPISVC.INF"); } if (hmodMapi32) FreeLibrary(hmodMapi32); if (hmodStub) FreeLibrary(hmodStub); } } }
Eventually an official answer.
It proves that we are on the right way :)
Thank's Stephen.
Would the above also work for mapisvc.inf as installed by Exchange?
Jules - Exchange doesn't use fGetComponentPath or any of the MSI stuff. It just puts/looks for the file in the system directory. If I didn't screw it up, the code above should fall back correctly to system directory.
I've tried using mfcmapi and I have one problem with it:
when opening email message with "Open Message" menu item, I get the Outloook form with "Reply" button available. But when pressing reply, though, I get new form where "Send" button is disabled !!???
Additionally, If I open email message with "Execute Verb on Form" and try verbs 100, 102, 103, 104 or 107 - I always get the form with "Send" button disabled !!???
I am using Outlook 2003.
Is it a bug or some security feature of Outlook?
Basically this ruins the usability of the "open non modal" code that I am trying to reuse.
Regards,
Miro
MFCMAPI only has a partial implementation of the form viewer classes. You might want to look at Goetter's book.
I could say: 'Forget what's said in KB article and follow documentation of FGetComponentPath, because it gives you all information you need. ' You have to read all stuff (component ID and LCIDs) from registry. We use it this way for more then 2 years without any problems.
1. KB article is quite old
2. FGetComponentPath is one of the undisclosed API functions (was a kind of secret thing 2 years ago).
Merlin - FGetComponentPath has been documented for many years now (well more than 2). As for the rest of your comment - yeah - that's exactly what I'm saying - the documentation explains all this and the code in the KB article needs work. That was the point of my post.
I managed to waste half a morning figuring out something I'm supposed to already know. Dev asked if I
Sorry for the ignorance, but were do you input this code? I'm new to this environment! This would be a solution for why my Outlook 2007 will not update on KB935569, as it keeps looking for my mapisvc.inf. TIA, Jeff
I don't think this code is for you. If you're having trouble applying a hotfix, call in to support to get someone to look at it.
I tried using some portions of the above code to see if it works with Chinese Outlook (2003) and it didn't. I ended up using the DLLPathEx subkey to find the path of msmapi32.dll. Any ideas of what could have been the problem
One possibility is that I hardcoded the value "FF1D0740-D227-11D1-A4B0-006008AF820E" instead of reading it from the registry. Perhaps MSIComponentID has a different value for the Chinese SKU?
When you say the code didn't work - what did it do? Throw an error? Give a directory you didn't expect? More details == better help.
I did think that could be the reason but the value for MSIComponentID in the registry is same as the one you specified in the post.
Sorry. Forgot to mention that it didn't give any errors but the result was always an empty string.
Hrmm - this might be a localization bug. It sounds vaguely familiar but I haven't been able to turn up any bug reports on it. You might try calling in for support to get it investigated in depth.