您什么时候selectExcel COM over Excel的C-API来定制Excelfunction？
看一下微软关于与Excel集成的概述：
他们将C-API，VBA和COM列为独立的API。 网页有两个看似矛盾的陈述：
– 一个
C API和XLL：与Excel集成的DLL。 这些DLL为添加高性能工作表函数提供了最直接和最快速的接口，尽pipe与后来的技术相比，它的代价是一些复杂的代价。
– 两个
自从Excel版本5引入Visual Basic for Applications（VBA）表单和版本8（Excel 97）中的Visual Basic编辑器（VBE）以来，用户自定义Excel的最简单方法是使用VBA而不是XLM。 因此，在更高版本的Excel中引入的大部分新function都可以通过VBA获得，但不能通过XLM或C API获得。 例如，几个命令，事件陷阱和增强对话框function可通过VBA获得，但不能通过XLM或C API获得。
一方面，C-API似乎是那些使用技术工具集的Excel集成的首选方法（因为它具有更高的性能）。 但是另一方面，对于现在已经不存在的扩展Excel的XLM方法来说，它看起来像是一个包装器，如果这实际上是一个需求，那么它的优势在于性能。
一般来说，我与Excel交互的目标是从单元格刮取值并发送到服务器，然后将值添加到单元格范围。 这样的function将基于来自定制function区的命令而湿润。
我认为这也将涉及到访问单元格属性，locking和解锁范围，以及与工作表的一般互动。
问题：
- 所有VBA与Excel的COM交互？
- VBA是否可以像C-API那样访问Excel的所有function？
- 为什么C-API不能访问Excel的COM？
由于有可用的COM和C-API访问工具（即ExcelDNA），COM和C-API的使用都是可能的。
-
VBA更紧密地集成在仅使用COM接口的Excel中。 例如，VBA允许创build用户定义的函数，而这些函数具有与包含VBA代码的工作簿相关的范围。 您只能使用公共Excel COM接口重新实现VBA集成。 VBA可以访问完整的COM对象模型。
-
您可以调用VBA代码中的所有工作表函数，并且可以通过C API调用所有工作表函数。 但是，正如您的引用所指出的那样，Excel的其他function不能通过C API获得，而只能通过COM对象模型（VBA可以访问）来实现。
-
C API是代码组件之间的一种二进制粘合机制，COM是代码组件之间的另一种二进制粘合机制。 Excel已经select通过这两种二进制粘合机制来公开不同的function集合。 从这个angular度来看，你的问题并不合理。
使用C API（.xll）开发的Excel加载项也可以使用COM对象模型（尽一切努力）。 COM插件使用C API会更困难，因为C API插件初始化的特性。
也许要突出你开始的两个引号的实际重要性：
假设您正在为Excel创build一个加载项，而不是使用VBA。 这可能是你想要使用其他语言（Python，.NET，C ++等）的情况。 然后你有两个集成机制，C API（.xll）和COM加载项模型。 在这两者中，只有C API允许您创build可从工作表中调用的高性能用户定义函数。 但是，COM对象模型允许在macros上下文中进行更好的操作，并且可以直接通过C API暴露额外的事件。 所以有一个权衡。
Excel-DNA（用于制作基于.NET的插件）等框架允许您构build使用C API进行集成的插件，还允许您与COM对象模型交谈。
为了更多地混淆事物，还有第三种插件机制，这是目前微软正在开发的唯一一种插件机制。 这是基于Javascript的“办公应用程序”。 与其他两个附加插件机制相比，这些特性集的function更受限制 – 它们不允许您创build用户定义的函数，您只能使用有限的对象模型进行交互，而且速度较慢。 但是基于Javascript的插件有一个很大的优势 – 它们运行在各种非Windows Excel平台上 – 基于Web的Excel，iOS和Android Excel版本以及Mac（和Windows）。