Microsoft Office Document Imaging V11.0 type library : "Class not registered"

From: Alexandre Kampouris (Xelax_at_Radio-BIP.qc.ca)
Date: 08/09/04 

Date: Mon, 09 Aug 2004 09:56:59 +0200

[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

Relevant Pages

  • Running Delphi from a portable drive?
    ... Delphi Setup Question which relates to my question; ... I would like a totally portable Delphi environment on portable storage ... The only problems I can envisage are with the registry and .INI files. ... Then, in the .REG file, use ...
    (borland.public.delphi.language.objectpascal)
  • Re: Delphi in Source Code Control System
    ... > It's legal as long as no one does use it that doesn't have a Delphi ... Unless your SCC was accessible via the web to the ... >> registry entries, environment changes, and DLLs registered. ... > (DCUs and BPLs at least). ...
    (borland.public.delphi.non-technical)
  • Re: Limited Users cannot run or install an application -
    ... not NTFS partition. ... How can I adjust the permissions in the registry as well,. ... application folder in question. ... I have an Delphi application ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Delphi License problem when changing Windows domain
    ... had to copy the registry entries as well so that it includes my libraries ... Andrew ... my Delphi does not load since it could not find the license. ... > changing domains you propably change the user name you login as well. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: cannot open office 2007
    ... Exit Registry Editor. ... Yes I did try what db offered and I still have the scan off in Norton, ... Office documents stays resident even if virus scanning is turned off and has ... Microsoft Office MVP ...
    (microsoft.public.office.misc)