HRESULT Error: Class not registered (FACILITY_ITF)

For an application that writes directly to an Excel file, I am getting a
walkback:  'HRESULT Error:  Class not registered (FACILITY_ITF)' when I try
to run:

(Smalltalk at: #XlApplication) new

It goes through the following stack:

OLELibrary(ExternalLibrary)>>invalidCall
OLELibrary>>coGetClassObject:dwClsContext:pServerInfo:riid:ppv:
IClassFactory class>>onCLSID:hostName:
XlApplication class(COMInterface
class)>>onCLSID:outerIUnknown:hostName:licenseKey:
XlApplication class(COMInterface class)>>onCLSID:outerIUnknown:
XlApplication class(COMInterface class)>>onCLSID:
XlApplication class(COMInterface class)>>new

All this is part of moving my development environment from a laptop to a
different computer.  On the new machine, from a fresh Dolphin image, I ran
code adapted from AXTypeLibraryAnalyzer class>>example3 and then generated
Excel classes using the ActiveX Component wizard.  Running the application
(which worked previously on the laptop) resulted in the above error.  I have
re-installed Office XP on the new machine but that did not help.  Any
suggestions?

Thanks.

Ted

"Ted Shen" <[hidden email]> wrote in message
news:400d6944$[hidden email]...
> For an application that writes directly to an Excel file, I am getting a
> walkback:  'HRESULT Error:  Class not registered (FACILITY_ITF)' when I
try
> to run:
>
> (Smalltalk at: #XlApplication) new
>

The error should be taken literally. It means that the machine on which you
generated XlApplication has something which the other machine does not. If
these are one and the same machine, it means that the typelibrary you
generated from is out of step with what you have installed, or that the
installation is corrupt/mismatched in some other way. At its most basic it
means that the component with the CLSID associated with the XlApplication
class is not registered on that machine. You can cross check this by looking
at the clsid method of the class, and then looking up the GUID you find
there in the registry under HKEY_CLASSES_ROOT/CLSID. The absence of a key
there with the correct GUID will cause that error.

The CLSID associated with a COM component can be very version specific. If
you know that you are not relying on features of a specific version, you can
use the version independent prog id instead. This might get something
working, but you are then more exposed to version incompatibilities. In this
case you could modify the #clsid method to return 'Excel.Application'
instead of the GUID.

It might be instructive to compare the registry entries under
Excel.Application on both machines. It should have sub-keys telling you the
CLSID (the prog id is just an indirect way of mapping a human readable name
to the CLSID), and also a CurVer key which will tell you the version
dependent prog id. I suspect you will find these differ between the
machines.

One other thing to check is that you are generating from the correct type
library. You may have more than one installed on the machine, perhaps from
an older Office installation. For example, on my machine I have both
versions 5.0 and 9.0 for Excel, only the latter now works.

Regards

Blair

Thanks.  After making sure the versions of the OS and of MS Office on the
new machine were the same as on the old machine, I fixed an error in the
code I had borrowed from AXTypeLibraryAnalyzer class>>example3.   I had been
specifying the type library as c:\Program files\Microsoft
Office\Office10\xl5en32.olb, but the correct type library for Office 2002 is
excel.exe.  This eliminated the 'Class not registered' error.  Then I used
the following code to open an existing Excel file:
xlApp := (Smalltalk at: #Xl_Application) new.
xlWorkbook := xlApp workbooks open: 'c:\test.xls' lcid: nil.

Ted


"Blair McGlashan" <[hidden email]> wrote in message
news:burodq$kt3io$[hidden email]... you
> generated XlApplication has something which the other machine does not. If
> these are one and the same machine, it means that the typelibrary you
> generated from is out of step with what you have installed, or that the
> installation is corrupt/mismatched in some other way. At its most basic it
> means that the component with the CLSID associated with the XlApplication
> class is not registered on that machine. You can cross check this by
looking
> at the clsid method of the class, and then looking up the GUID you find
> there in the registry under HKEY_CLASSES_ROOT/CLSID. The absence of a key
> there with the correct GUID will cause that error.
>
> The CLSID associated with a COM component can be very version specific. If
> you know that you are not relying on features of a specific version, you
can
> use the version independent prog id instead. This might get something
> working, but you are then more exposed to version incompatibilities. In
this
> case you could modify the #clsid method to return 'Excel.Application'
> instead of the GUID.
>
> It might be instructive to compare the registry entries under
> Excel.Application on both machines. It should have sub-keys telling you
the
> CLSID (the prog id is just an indirect way of mapping a human readable
name