0

I am trying to display a new Word document inside a Widget, using OLE. This works fine as long as I compile my application under x86 architecture. Now I tried porting my application to x64 and it stopped working. The call to OleCreate() fails with REGDB_E_CLASSNOTREG.

CLSID clsID;
IUnknown* pIUnknown;
HRESULT res = CLSIDFromProgID(L"Word.Document.8", &clsID);
if (SUCCEEDED(res)) {
   res = OleCreate(clsID, IID_IUnknown, OLERENDER_DRAW, NULL, NULL, storage, reinterpret_cast<void**>(&pIUnknown));
}

After some research I came across some solutions, but none of them were applicable.

  • I can't set my compiler to x86 when I'm trying to port my application to x64 so following Post hasn't solved my problem.
  • I tried calling regsvr32.exe withC:\Windows\System32\ole32.dll but it didn't change the result.
  • I tried installing the hotpatch, which was shipped by microsoft to fix the same problem with OleCreateFromFile(). Sadly it doesn't fix the problem for OleCreate() - hotfix

The only solution, which worked so far was to copy the content of HKLM\SOFTWARE\SysWow64\Classes\CLSID\<CLSID of Word Document> into HKLM\SOFTWARE\Classes\CLSID\<CLSID of Word Document> but this is more of a hack than a fix, because I would have to modify the registry of every machine on which I want to run my application. Since this task requires administrator privileges, I can't do this from inside my application.

I need a solution which works and doesn't force me to manually alter registry entries.

I'm running my application on a Windows 7 Professional SP1 64-Bit machine with a 32-Bit Office 2010.

Community
  • 1
  • 1
whY
  • 189
  • 1
  • 10

1 Answers1

0

After some more testing I found the solution to the problem, which was to use Word.Document instead of Word.Document.8 as progID. I have don't know why this seems to be a problem with 64-Bit compilation. The thing, I noticed though was that CLSIDFromProgID() now resolves to a different CLSID.

whY
  • 189
  • 1
  • 10