What is the difference between how Excel exposes the COM API compared to the C-API

Question

I'm using the ExcelDNA library, which seems to use a combination of Excel's C-API and COM interface.

How are these interfaces different in terms of implementation by Excel? From the Microsoft site (https://msdn.microsoft.com/en-us/library/office/bb687829.aspx):

" Customizing the Excel User Interface

For many versions of Excel, the C API has not been the best choice for customizing the user interface. VBA has superior access to Excel objects and events. The user interface introduced in Excel 2007 is significantly different from earlier versions both in appearance and underlying technology. You can best customize this interface by using managed code resources."

What makes COM more suitable for editing Excel's UI than the C-API?

Answer 1

Its easier and faster to write user-interface stuff using VBA or .NET rather than C or C++.

The COM interface has access to a much richer set of Excel objects and events than the C-API interface but the C-API is preferred for writing UDFs because it performs substantially better than COM and allows things like multi-threading, async, RTD, cluster etc that COM does not offer.

Note that using COM from ExcelDNA means using COM-INTEROP which is inherently slow.

Answer 2

I agree with Charles regarding the ease and lower TCO of building UI components and quickly prototyping new features using C# and Excel DNA (or Addin Express to be fair).

Before declaring that performance is of paramount importance, do set some expectations and measure the calculations or events involved. If there is a truly performance sensitive section, isolate it and then write managed C++ code that could then be integrated with the UI written in C# or VB.NET.

Also, just a minor correction to Charles' comment regarding Excel DNA and VBA; they do work together. A couple of examples can be found at:

• ExcelDNA Blog on VBA Integration
• Mike Juniper Blog on Integrating ExcelDNA and VBA