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]... > "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 > 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 > > |
Free forum by Nabble | Edit this page |