Excel VBA：为什么 API 比 SendKeys 好？

Question

我目前正在 Excel 中处理一个 VBA 项目，我需要解锁一个 VBProject 并锁定另一个 VBProject。到目前为止，我一直在用 SendKeys 做这件事，但我一直读到这不是一个好方法，API 更好？ （例如在这个线程中：Unprotect VBProject from VB code）

但是，在我的研究过程中，我找不到任何关于原因的详细信息。

有人能告诉我为什么 SendKeys 不好吗？哪些事情可能会出错？ （请注意，我的 SendKeys 序列最多只有 1.5 秒长。） 另外，为什么 API 是更好的方法？

谢谢！ :)

Answer 1

WinAPI 使用诸如 window 句柄之类的东西（您可能以前在代码中见过 hWnd？）来定位特定的 window。一旦你有了这个，你就可以向 window 发送和接收消息，而不管它是 window 状态（active/inactive）等

您正在直接处理对象，这才是编程应有的方式。

SendKeys() 方法只是模拟用户在键盘上敲击按键，而不管 window 打开的是什么以及在哪里 - 所以它自然地将输出发送到任何活动的对象并且能够接收它。

---

另一种思考方式

如果您要编码以在 VBA 中某个 sheet 的单元格中放置一个值，您可以执行以下操作：

Range("A1").Value = "Foo"

这一切都很好，但它假设我们想要的 sheet 是当时活跃的 sheet。如果不是，则会填充错误 sheet 上的错误单元格。这实际上就是您使用 SendKeys()

所做的

另一方面：

Workbooks("Target Workbook.xlsx").Sheets("Target Sheet").Range("A1").Value = "Foo"

在我们要定位的确切工作簿中指定确切的单元格，在确切的 sheet 中 - 因此，如果那个 sheet 在那个时间点不活动，那么不用担心！它仍然会到达正确的位置（这就是您使用 API 所做的事情）

---

注意事项

在 VBA 中使用 WinAPI 如果您不知道自己在做什么，可能 会有风险 - 这些方法的代码是在外部库中预编译，这意味着您的 VBE 错误处理程序不会有任何用处。如果你在 API 上犯了错误，你 运行 有损坏你的工作簿的风险（或者更糟，这取决于你实际在做什么）。

您还需要查看 VBA 中的条件编译，因为您必须根据使用的是 32 位还是 64 位版本来不同地声明函数和参数。