为了扩展Garath's observation,Workbook 是 _Workbook 和 WorkbookEvents_Event 的组合。
基本上,_Workbook 接口是 Excel 实现的,WorkbookEvents_Event 接口是它引发的事件。
在 COM 中,WorkbookEvents_Event 是一个源接口,实际上为客户端定义了方法签名以注册为事件接收器(也称为事件处理程序)。 Workbook 接口是将其联系在一起的实际 coclass(COM 类) - 该类公开 _Workbook 方法,并且是 WorkbookEvents_Event 的源。
在 COM 中,_Workbook 接口将从对 IUnknown::QueryInterface(这是您与 Excel 交互的方式)的调用返回,而 WorkbookEvents_Event 将从 IConnectionPoint::GetConnectionInterface 返回。反过来,要订阅 Workbook 的“事件”(COM 中的连接点),您需要将 WorkbookEvents_Event 的实现传递给 IConnectionPoint::Advise 以便 Excel 在事件发生时调用。
当它被翻译成 .NET 时,这些源接口在很大程度上失去了意义,变成了实现细节。强类型的委托简化了事情,COM 互操作自动化了任何死记硬背的接口魔法。
在大多数情况下,仅使用 Office 互操作(工作簿)的 coclass 接口就足够了,并且最接近 .NET 模型。但是请注意,我已经看到其他供应商建议使用实际的包装器(例如,WorkbookClass)而不是生成的接口(Workbook)来进行未来的版本控制。老实说,我(谢天谢地)从来没有考虑过任何一种方式的后果。
哦,下划线主要是一种约定,也是一种在给定类名的情况下生成 COM 接口名的便捷方式。 VB6 将为具有该约定的类创建 COM 接口(例如,如果您有一个名为 Workbook 的类,它将导出一个 COM 接口 _Workbook),因为它是一个无效的 VB6 名称。通常,前导下划线是无效标识符 (VB6) 或保留标识符 (C++),因此可以方便地自动生成名称。