Question

我是一个使用Interop的工作表对象实例。 MSDN解释它的方式是：

xlsApp = DirectCast(CreateObject("Excel.Application"), Excel.Application)
xlsWB = xlsApp.Workbooks.Add
xlsWS = DirectCast(xlsApp.Worksheets(1), Excel.Worksheet)

这项工作正常，但我仍然有两个问题。是不是xlsApp.Workbooks.add创建了一个Excel.Workbook而不是一个Object，因为我不必将它转换为工作簿，因为我必须使用Application，Worksheet和Range？

二。我想知道为什么他们使用xlsApp.Worksheets(1)来生成新的工作表。为什么不使用xlsWB.Worksheets(1)，因为它属于xlsWB（在我看来）。 xlsWB.Worksheets也有效，所以有什么不同，xlsApp.Worksheets(1)为什么会工作？

代码行将更改为：

xlsWS = DirectCast(xlsWB.Worksheets(1), Excel.Worksheet)

编辑：我的变量声明：

Private xlsApp As Excel.Application = Nothing
    Private xlsWB As Excel.Workbook
    Private xlsWS As Excel.Worksheet

Answer 1

Excel自动化对象模型具有一定的冗余，允许您以多种方式完成工作。每当遇到这样的问题时，请务必阅读MSDN文档。您会看到Application.WorkSheets说：

返回表示活动工作簿中所有工作表的表单集合

突出显示相关短语。可能在您的代码中正常工作，因为电子表格只有一个WorkBook，您添加的那个。因此获得错误表单的风险很小。如果您打开一个当然包含多个工作簿的电子表格，则不一定如此。或者，如果您的代码与主动编辑电子表格的用户交互，那么您可能真的喜欢使用活动工作簿。您应该偏爱WorkBooks.WorkSheets属性，不会发生任何意外。

从MSDN文档中也可以清楚地看到对转换的需求。如果您点击Excel.Sheets链接到达Sheets.Item property（默认属性，您不在代码中命名），那么您会看到它返回Object。在Office Automation界面中很常见，有许多访问器可以返回不同类型的接口，具体取决于您选择的对象的风格。因此，对于该属性，必须从Object转换为Worksheet。

使用WorkBooks.Add()时无需强制转换，只需返回WorkBook接口即可。

请记住，您使用的是VB.NET，这种语言经过优化，可以轻松编写这种动态代码。它的技术名称是后期绑定，在运行时而不是编译时发现接口的成员。它确实有缺点，更容易在您的代码中犯错误，直到运行时才会发现，例如拼写错误的成员名称。 Option Strict On禁用后期绑定，您必须明确强制转换。不幸的是，VB.NET失去了在动态早期和晚期绑定之间来回切换的能力，这是对类型推断的额外支持的牺牲品，它没有类似于C＃v4 动态的任何东西关键字。

如何使用interop实例化工作表？

1 个答案: