work in progress
- ExcelXP, Excel2000, Excel97 - those units are just brushed-up polished in-house versions of standard ActiveX import. You can use them, or you can always do you own import using standard Components / Import Active X menu.
Dynamic linking like shown in MArtynA's answer can work too, but it will strip you from benefit of compile-time syntax checking.
var Excel: Variant; // or OleVariant
...
Excel := CreateOleObject('Excel.Application');
If you mistyped some identifier, or used a property/method not yet or no more supported in your Excel version - you would only know it when your Application will try to use it, compilation would not alert you.
The runtime the code generates an error: “TExcelApplication cannot be found” means you broken DFM streaming. In particular, ReadComponent function parsing DFM resource of your application finds it need to load a class named 'TExcelApplication' - but there is no such class in the dictionary. Use RegisterClass(TExcelApplication); in the unit initialization section. Or move the object declaration back to published section of your form's class - then Delphi RTL would transparently do this call for you.
"the IDE reports TExcelComponent “cannot be found”" and " install a Office package in Delphi" - indeed, see Error opening a dfm file - Class xxxx not found
"The bpl file in the embarcadero subdir of program files doesn’t exist on my system" - would it be so, you would not be able to tick the checkbox, because that exactly tries to load the design-time BPL into your IDE. And that would give you a very different error, about inability of loafing your BPL.
Personally i never install Delphi into Program Files, both because some old code might fail with long and space-containing paths, and because i prefer to have options of tinkering with development tools without hassle of UAC (User Access Control of Windows Vista+), including its virtual shadowing filesystem (%LocalAppData%\VirtualStore).
In my XE2 installation the source .pas files lie in c:\RAD Studio\9.0\OCX and c:\RAD Studio\9.0\bin has THREE dcl*office*.bpl - for Office 2000, XP and 2010.
Are you sure you have neither? Search all you disk for files like that then.
Still not found - run Delphi installation, "Modify" and make sure you made Office sample automation components actually installed. Try to use OfficeXP or Office2010 packages - they should be backward-compatible with Office 2000, due to Microsoft COM guidelines.
If still not found you might do Components / Import Component / Import ActiveX for Excel.
Also, i wonder seeing RxLib in your list. Officially RxLib ended with Delphi 5 and never supported Delphi6+, instead donating to JediVCL project. The unofficial patches existed (by Polaris Software for example), but i wonder if they invested a lot of support into Unicode versions of Delphi. Even J.E.D.I. lacks manpower badly today.
Also, thing again if you need a full-fledged Excel interoperation. It gives you VBA-level access to Excel's internal object tree. But it burdens your users with need to purchase and install Excel, and it also is rather slow. If you only use limited subset of the Excel Workbook features generating XLSX files in your program might be both faster and leaner. At least this is the way we switched to in our app. Now users you can export spreadsheets no matter if Excel or some other office or none at all is installed, and do it much faster.
