您何时会选择Excel COM而不是Excel C-API来自定义Excel功能？

查看Microsoft关于与Excel HERE集成的概述：

他们将C-API，VBA和COM列为单独的API。该网页上有两个看似矛盾的陈述：

-一个

C API和XLL：与Excel集成的DLL。这些DLL为添加高性能工作表功能提供了最直接，最快速的接口，尽管与后来的技术相比，其代价是有些复杂。

-两个

自从在Excel版本5中引入Visual Basic for Applications（VBA）工作表和在版本8（Excel 97）中引入Visual Basic编辑器（VBE）之后，用户自定义Excel的最简单方法是使用VBA而不是XLM。因此，可以通过VBA而不是XLM或C API获得更高版本的Excel中引入的许多新功能。例如，一些命令，事件陷阱和增强的对话框功能可通过VBA获得，但不能通过XLM或C API获得。

一方面，对于具有技术工具集的人来说，C-API似乎是首选的Excel集成方法（因为它的性能明显更高）。但是另一方面，对于扩展Excel的现已淘汰的XLM方法来说，它似乎是一个包装器，如果实际上是必需的，它具有执行性能的优势。

通常，与Excel进行交互的目标是从单元格中抓取值并将其发送到服务器，然后将值添加到单元格范围中。这种功能将主要基于来自自定义功能区的命令。

我认为这还将涉及访问单元格属性，锁定和解锁范围以及与图纸的一般交互。

问题：

VBA与Excel的所有交互都是由COM完成的吗？

VBA是否可以像C-API那样访问Excel的所有功能？

为什么C-API不包括对Excel的COM的访问？

由于存在允许COM和C-API访问的工具（即ExcelDNA），因此COM和C-API都可以使用。

仅使用COM接口，VBA与Excel紧密集成在一起。例如，VBA允许创建用户定义的功能，并且这些功能具有与包含VBA代码的工作簿相关的范围。您不能仅使用公共Excel COM接口重新实现VBA集成。VBA可以访问完整的COM对象模型。

您可以从VBA代码中调用所有工作表函数，也可以通过C API调用所有工作表函数。但是，正如您的报价所示，Excel的其他功能不能通过C API使用，而只能通过COM对象模型（VBA可以访问）才能使用。

C API是代码组件之间的一种二进制粘合机制，COM是代码组件之间的另一种二进制粘合机制。Excel已选择通过这两种二进制粘合机制公开不同的功能集。从这个角度来看，您的问题没有任何意义。

使用C API（.xll）开发的Excel加载项也可以使用COM对象模型（需要付出一些努力）。由于C API外接程序初始化的特殊性，COM外接程序将更难使用C API。

也许要强调您以两个开头的引号的实际重要性：

假设您要为Excel制作外接程序，而不使用VBA。如果您想使用另一种语言（Python，.NET，C ++等），可能就是这种情况。然后，您有两种集成机制，即C API（.xll）和COM加载项模型。在这两个函数中，只有C API允许您创建可以在工作表中调用的高性能用户定义函数。但是，COM对象模型允许在宏上下文中进行更好的操作，并公开您可以通过C API直接看到的其他事件。因此需要权衡。

诸如Excel-DNA（用于制作基于.NET的外接程序）之类的框架使您可以构建使用C API进行集成的外接程序，还可以与COM对象模型进行通讯。

更令人困惑的是，还有第三个外接程序机制，这是Microsoft目前正在进一步开发的唯一机制。这是基于Javascript的“ Office应用程序”。这些功能在功能集方面比其他两种附加加载项机制更受限制-它们不允许您创建用户定义的函数，与您进行交互的对象模型有限，而且运行缓慢。但是基于Javascript的加载项有一个很大的优势-它们可以在各种非Windows Excel平台上运行-基于Web的Excel，iOS和Android Excel版本以及Mac（以及Windows）。