🚀 go-pugleaf

[Message crossposted to microsoft.public.win32.programmer.ole and
borland.public.delphi.oleautomation ; fu2 to
microsoft.public.win32.programmer.ole ]

Hi everyone,

Even though I am a neophyte to COM programming, I believe there is a bug
in Microsoft's type library for the Document Imaging component of the
Office 2003 suite. I don't really know what to do next.

I want to develop a Delphi 6 application using Microsoft's Office
Document Imaging type library. This library provides TIFF document 
displaying as well as a good quality OCR facility derived from 
ScanSoft's OmniPage software. These components are included with
Microsoft Office 2003.

The problem in a nutshell : I am getting a "Class not registered" 
message every time I try to run my program only with the particular 
class I'm interested in. Microsoft's own OLE/COM Object viewer is 
apparently afflicted with exactly the same problem when I try to view 
this library.

The problem appears to be independent of the configuration (ie, XP Pro
host or W2K host, without or with all the latest service packs for both
the OS and Office).

The story :

Delphi 6 had no problem whatsoever generating a TLB file for this
particular class, which I find puzzling in view of the error message 
later obtained. I can find  entries in that file for just about every 
control described in Microsoft's documentation (see 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Mspauto/html/dihowUsingMODIViewerControl.asp 

) . You may have a look at this MODI_TLB file here : 
http://Radio-BIP.qc.ca/OLE/modi_tlb.pas.txt . (The added .txt suffix is 
just there to make the file name browser friendly).

I've looked at the registry, the information appears to be OK for just 
about every key I looked at - the DLL modules are at actually the 
location stated in the registry.

I then wrote a small program which I compiled and ran from the commmand 
line. (It's a lot simpler for me that way, and it lets me concentrate on 
the issue, whereas the IDE forces me to keep track of a lot more stuff). 
All the program does is to try to start the viewer component.

The program is here :
http://Radio-BIP.qc.ca/OLE/tm.pas

When I run the program, MODI_TLB.CoDocument.Create appears to return a 
valid pointer. However the next step, invoking modiDOC.create to open a 
document, always fail with a "Class not registered" error.

d:\MODI>tm
0                     <- pointer is nil
9070512               <- Filled by CoDocument.Create
ici                   <- Kilroy was here
Exception EOleException in module tm.exe at 00055BBC. <- aaargh !
Klasse nicht registriert.  <-"Class not registered"

After a lot of mucking about, googling, teeth gnashing, head scratching, 
I came across a Microsoft utility called "OLE/COM Object viewer", 
available at http://www.microsoft.com/com/resources/oleview.asp .

I ran it, and to my surprise, that program produces what appears to be 
*EXACTLY* the same error when I select the library I'm interested in. It 
works flawlessy for every single other component. This means to me that 
my Delphi program is not (necessarily) at fault, and that the problem 
probably lies elsewhere.

Here's what OLEview looks like when it's happy, in the present case I'm 
looking at the "Outlook View Control":
http://Radio-BIP.qc.ca/OLE/ole1.gif

And that how the *error* appears when access to the Office Document 
Imaging Type Library is attempted :
http://Radio-BIP.qc.ca/OLE/ole2.gif

I suppose the "Library not registered" / TYPE_E_LIBNOTREGISTERED errors 
to be the same as the "Class not registered" I got from my Delphi program.

Looking closer at the error box, I see that this message is issued by 
the LoadRegTypeLib API function.

I ran REGEDIT, the key listed in the error box *IS* registered. The 
version number appears to be coded in HEX (b.0) in the registry whereas 
it is displayed as 11.0. I don't think this could be the problem. I've 
made a quick try modifying the registry Version key from b.0 to 11.0, to 
no effect.

Anyway, a version error would be displayed as such, according to the 
LoadRegTypeLib info :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap9_5jj6.asp

The present error would fall under the "Other return codes" row...

The above investigation was conducted on a German language XP 
Professional machine with the latest service packs for both the OS and 
Office. I tried installing Microsoft Office on another machine running 
an English language Windows 2000, while avoiding running anything 
related to Delphi in case this were the cause. The results were 
identical, so the problem is apparently not OS related.

I can't understand how Delphi could find a module and build a translated 
type library where Microsoft's own program can't.

Out of despair, I tried to run regsvr32 on just about every DLL and EXE 
files under
C:\Programme\Gemeinsame Dateien\Microsoft Shared\MODI\11.0
(in an English language edition of Windows that would be
C:\Program Files\Shared Files\Microsoft Shared\MODI\11.0 )

No improvement.

Could it be possible that perhaps the library itself calls another 
library, the latter being not properly registered ? But the Document 
Imaging application (Version 11.0.1897.0) works without any problem.

What could I try now ?

I don't have any experience with Microsoft Customer Service - I suppose 
that their level of problem solution is of "Where is the power switch" 
kind. Application development support is provided for a hefty fee - I 
could go for it if is were refundable should it be established that the 
problem is a bug in *their* stuff. I could also try going through my 
employer, as Office 2003 was obtained under the Home Use Program, and 
that my application is actually destined for my work. But I would have 
liked to have a working demo of my concept to my colleagues without 
having to provide long explanations up front what I was trying to 
achieve - and receive a flat "no, get lost".

Is there anything more I could try locally ? One idea could be to try 
loading the library directly from the DLL file using LoadTypeLib ( 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap9_1axu.asp 
) without going through the registry, but this would be a lot of work 
and not very portable.

I had managed to make some use of the functionality included in Office 
2002. However I really need the features of this Document Imaging library.

Thanks in advance,

Alexandre