vba - .Select、.Activesheet、.Activecell 等...

Question

对于这个问题，我引用下面的帖子来澄清自己:
Why is my conditional format offset when added by VBA?

在我这些天看到的很多很多帖子中，OP 都被默默地允许使用 .Activate、.Select、.Offset 等...而它们却为潜在错误(通常是由最终用户引起的)敞开了大门。 .
有时甚至支持该代码。

我的问题:是否存在一种有效的情况，您可以在没有直接替代方案来捕获这些 stmts 产生的典型错误的情况下使用这些语句中的任何一个？

我指的是动态解决方案，我认为这是开发 Excel 时必须的解决方案。就我个人而言，在六年多的时间里，我不记得有任何一个案例需要它；它似乎总是最糟糕的选择之一。在我以前的公司中，永远不要使用它是一条无声的规则，它只会让我的 VBA 生活(以及最终用户的生活)变得更好。

为什么我提出这个问题是因为我认为让 VBA 新手意识到他们在使用这些语句时所承担的风险是值得的(通过经验证明，当最终用户做了一些意想不到的事情时，他们最终不会这样做)对 VBA 没有任何感情)并提出直接的替代方案(我不会说我自己之前总是这样做，但我直觉地认为，仅仅为已经存在 bug 的怪物提供快速解决方案是有问题的)。

我相信，当默默地允许(在这种情况下它会自动增强)时，刚开始的 VBA 开发人员将以错误的方式创建越来越多的工具(因此新手也会继承这种行为 - 他们也将从 Stack Overflow 中学到这一点)因为 Google 返回了他们寻找的结果 (!))。
如果开发人员不知道为什么他“可以”使用“选择”以及在哪些情况下它是潜在的错误，那么他永远不应该使用它。就我个人而言，我可能会在立即窗口中使用 select stmt 对动态范围定义(错误模式)进行一些快速检查，但不会在书面代码中使用。

结果使得 VBA 最终比现在更加不受欢迎；如果出现问题，该语言将成为受害者(但恕我直言，它仍然是 Excel 和 Access 应用程序可用的“最佳”编程支持)。我在一家大公司里见过这种情况发生太多次了，那里的 VBA 总是“狗屎”。

这只是我自己的真实经历。
这不是对错的问题，而是对错的问题。我有兴趣听听您对这个问题的看法。

Answer 1

我同意 Select 和 Activate，但不同意 ActiveWorkbook、ActiveSheet 和 ActiveCell(我同意它们被滥用，但并不是说它们本身应该避免)。这些肯定有合法用途。我有一个程序可以自动执行“填充系列”，从 ActiveCell 执行此操作。我的程序无法预测将使用哪些单元格；由用户来选择它。这是用户界面的一部分。

但是，在三种情况下我不得不使用 Select(现在我读到了四种有关缩放的内容，但我从未使用过它)。

1. 条件格式。有一种解决方法可以使用 Application.ConvertFormula，但它比仅仅存储选择、选择正确的单元格、执行操作并重新选择先前的选择更糟糕。
2. 数据验证。同样的原因。
3. 形状。我希望我能记住这些细节，但自从我使用 Shapes 以来已经太久了。有些事情如果不先选择形状就无法完成。

摆脱选择和激活代码是一场崇高的战斗。