Class definition EXCEL.APPLICATION is not found.

[kiyo]

My client installed the 64-bit version of Microsoft Office.
A program that edits Excel sheets using Excel automation is now throwing an error.
The error message is: "Class definition EXCEL.APPLICATION is not found."
This program runs without any issues on the 32-bit version of Excel.

The line where the error occurs is:
oExcel = CREATEOBJECT("Excel.Application")

I checked the version of Office and changed it to:
oExcel = CREATEOBJECT("Excel.Application.16")
However, this results in the error:
"Class definition EXCEL.APPLICATION.16 is not found."

Am I missing something?
Do I have to ask the customer to reinstall the 32-bit version?

 

[GTGeek88]

You can also start Excel like this if you are opening a file:

oWB = getobject(this.FileName)
oXL = oWB.application
oWS = oWB.Sheets(1)

Then you can do this:

CellVal = oWS.Cells(1, "A").Value

Not sure about 32 vs. 64, off-hand.

 

[Chriss Miller]

It's a sign the Office version is not installed as desktop version, but as "Office on Demand", where the office application you use is streamed but not actually installed. Such an Office version can't be automated.

 

[kiyo]

oExcel = GetObject("C:\C\AA.XLSX", "Excel.Application")
The same error occurred.

I have confirmed that his version of Excel is the 2019 desktop version.
My version of Excel is the 2021 desktop version (64-bit), and I have confirmed that it functions correctly.
It seems that he uninstalled the web version of Microsoft Office before installing the desktop version.
The .xlsx files are correctly associated with Excel, and double-clicking a file launches Excel properly.

 

[Paul Gibson]

VFP applications can definitely automate the 64-bit version of Excel, mine is 64-bit and automates fine from VFP applications, where the starting point is that same CreateObject("Excel.Application") function call.

Whether the CreateObject("Excel.Application") function call works is entirely based on what kind of installation the workstation has of Office (or standalone Excel), whether that installer installed the correct resources, including putting the correct keys in the Windows Registry and that's obviously more to do with the OS/Office/Excel than your application.

When you call CreateObject() with a string that VFP doesn't internally recognise and is not within it's CLASSLIB it has to rely on the operating system and the Windows registry for the success or failure of the job. We can trace it through to make some sense of it using "Excel.Application" as the example and opening the Registry Editor to see what happens.

Firstly, take the string "Excel.Application" and look for that item in HKEY_CLASSES_ROOT, so the first key we're looking for is HKEY_CLASSES_ROOT\Excel.Application, it's important to note here that if the key HKEY_CLASSES_ROOT\Excel.Application does NOT exist, that's when you'll get the error "Class definition EXCEL.APPLICATION is not found.", essentially the task has failed at the first step, it can't recognise the name.

The name doesn't mean anything INTERNALLY to VFP, like "Textbox", "Label" etc, if the name isn't part of the class library (CLASSLIB) and also can't be found when looking in the registry then the class definition is not found and you get the error you are seeing.

If HKEY_CLASSES_ROOT\Excel.Application does exist you'll probably notice that it has a key HKEY_CLASSES_ROOT\Excel.Application\CurVer which specifies that actual version. This is why, in our application code we are always better calling the code CreateObject("Excel.Application") rather than CreateObject("Excel.Application.16") or any other specific version. The point being that you should ALWAYS ask for the generic ("Excel.Application") and let the registry automatically point the way to the specific, than ask for a specific. You don't know at design-time and compile-time what specific version of Excel/Office any given user is going to have so the standard is ask for the generic and you'll always get the specific back automatically, as long as the installation of that application has put all the correct resources on the machine and put the correct keys in the registry.

On my machine the CurVer is Excel.Application.16 and I also have a key HKEY_CLASSES_ROOT\Excel.Application.16 and within that in the registry tree is HKEY_CLASSES_ROOT\Excel.Application.16\CLSID. That key contains the GUID which uniquely identifies the Class, which for this version of Excel is {00024500-0000-0000-C000-000000000046}

Knowing that GUID you can also trace through HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046} and within that key there are plenty of items that help VFP and the OS and Excel (in this case) instantiate the automation object, a good example being the key HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer32 which for me has the value: C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE /automation, which you can see is the command line required for executing Excel.exe specifically with the /automation parameter.

If you are getting the error "Class definition EXCEL.APPLICATION is not found." that means something in that workflow is not there, most likely the bit at the very beginning where it needs the key HKEY_CLASSES_ROOT\Excel.Application. This is NEVER the fault of your application, it is due to the installation of Excel and what the user does or does not have.

Microsoft have not made things easy in recent times because they've come out with lots of different versions of their office suite and the application within. They have offered Web versions and "click-to-run" versions along with their standard locally installed desktop versions. Some of these versions cannot be automated, i.e. the installation or way of accessing these versions is not compatible with instantiating the Excel automation object and in these cases some of all of the registry keys I mentioned above are not present.

In our application we detect whether Outlook, Excel and Word are available to our system, specifically by looking in the registry for the keys such as HKEY_CLASSES_ROOT\Outlook.Application\CurVer, HKEY_CLASSES_ROOT\Excel.Application\CurVer and HKEY_CLASSES_ROOT\Word.Application\CurVer, we look specifically for the CurVer key and capture that value. If the key doesn't exist or the value isn't what we'd expect then we flag that the workstation doesn't have Outlook, Excel, Word (as appropriate) so the application can bypass all code that relies on those aspects and avoid any errors that are easily avoidable.

Users sometimes tell us that we're incorrectly assuming/detecting that Excel or Outlook are not on the machine and in almost every example of a user telling us we're wrong, we find that they don't access those application in a traditional installed application manner and we'd never be able to automate it so our application is correct to bypass the automation code. In short, we protect ourselves from the "Class definition EXCEL.APPLICATION is not found." error by proactively checking for that class definition before we call the CreateObject() function and if it is not found then we avoid relying on it.

We recently had a user tell us that our Outlook automation code was broken. They'd previously been working fine but then decided to uninstall the classic version of Outlook and replaced it with Outlook (new), which we believe is a wrapper around the web version. Since they did that our application would no longer automate Outlook, they rolled their decision back and re-installed the classic Outlook and all the automation functionality came back because the automation object was available to our application again. So they tried again, uninstalling classic and replacing it with Outlook (new) and each time they replicated the same problem. Our application could no longer get the Outlook automation object. I explained to the user that they already knew what the solution was, they'd proved it themselves, but they insisted that they had to work with Outlook (new) instead. In the end we told them that they could keep trying, if they were certain that it'd work but they'd probably have to be very thorough and ensure clean uninstalls and clean installs but it was out of our hands. We could even go into our toolkit application and show them manually.... if the command line loOutlook = CreateObject("Outlook.Application") does not work, either because the class is missing or not understood or there is any other error when the object is instantiated then that's the issue of the application version, edition and installation.

There is only so much you can do. If the CreateObject("Excel.Application") function call fails, there isn't really anything you can do in code, you just have to encourage the user to install a version that can be automated. If they are definitely trying to install an edition/version which traditionally can be automated but still that command fails, it could be that their installation is wonky, damaged in some way. You could perhaps help them investigate the problem but if you look in their Windows Registry and HKEY_CLASSES_ROOT\Excel.Application is missing then you aren't going to have an easy job manually fixing things when the first breadcrumb is missing.