所以我正在使用我的程序。 它工作和运行，所以我复制了它并制作了第二个版本，我可以添加额外的功能，同时仍然有一个工作程序。 我没有看到我的新代码有任何问题，所以我准备逐步通过它。 突然之间，在我的其他版本中完美运行的东西会导致编译错误。 详情如下。
Dim elapsedTime As String Dim startTime As Date startTime = Now() 'code elapsedTime = Format(Now() - startTime, "h:m:s")我一次又一次地检查，但这个完全相同的代码在我的其他文件中工作正常。 在此文件中，它突出显示“格式”并抛出以下编译错误。
有谁知道为什么excel会对此感到沮丧？ 如果存在编译错误，我是否应该查看它突出显示的位置？
So I'm working with my program. It works and runs, so I copied it and made a second version which I can add extra features to while still having a working program. I don't see any problems with my new code, so I prepare to step thru it. Suddenly things which work perfectly fine in my other version are throwing compile errors. Specifics below.
Dim elapsedTime As String Dim startTime As Date startTime = Now() 'code elapsedTime = Format(Now() - startTime, "h:m:s")I checked again and again, but this exact same code works fine in my other file. In this file, it highlights "Format" and throws the following Compile Error.
Does anyone know why excel would be getting so upset at this? If there are compile errors, should I even be looking at the places it highlights at all?
最满意答案
你有一些名为Format东西在范围内（即可以从调用Format函数的位置访问），而Format东西正在影响你要调用的Format函数。
正如YowE3K建议的那样，如果右键单击该Format调用并选择“Definition”（或Shift + F2 ），则会转到阴影声明。
从那里你有几个选择：
重命名Format标识符[可能会破坏代码中的大量内容] 完全限定Format调用，即VBA.Strings.Format ，或者只是Strings.Format ，甚至是VBA.Format 。我的建议是完全限定该调用，然后再次尝试编译，并完全限定导致相同编译错误的任何/所有调用。 然后重命名名为Format任何内容，以便它不再影响 VBA标准库中的函数。
如果您正在使用Rubberduck （我管理的开源VBIDE加载项项目），您可以轻松找到阴影标识符的所有引用：
Rubberduck工具栏会告诉您Format何时引用了正确的函数：
而且您也可以轻松找到所有对此的引用，无论是否合格 - 因此无论何时何地都可以轻松完全限定它们。
通过搜索/替换失败的方式，Rubberduck还可以轻松地重构/重命名函数：
巧合的是，目前正在进行新的代码检查，特别是定位这样的阴影标识符 。
至于ByRef参数类型不匹配，看起来你的截图与你发布的代码不匹配，所以一切MakeEqn可能，但除非在该MakeEqn函数的主体中分配了eqn （它应该返回 ，而不是分配 ），然后没有必要传递它ByRef （隐式或显式） - 它可以传递ByVal （Rubberduck为您提供检查结果 - 另一个用于隐式返回类型，另一个用于两个过程上的隐式Public访问修饰符，以及几个其他用于您发布的代码中的其他问题）。
You have something named Format somewhere that's in-scope (i.e. accessible from where that Format function is being invoked), and that Format thing is shadowing the Format function you mean to call.
As YowE3K suggested if you right-click on that Format call and select "Definition" (or Shift+F2), that will take you to the shadowing declaration.
From there you have several options:
Rename the Format identifier [and possibly break a ton of things in your code] Fully-qualify that Format call, i.e. VBA.Strings.Format, or just Strings.Format, or even VBA.Format.My suggestion would be to fully-qualify that call, then try to compile again, and fully-qualify any/all calls that cause that same compile error. Then rename whatever it is that is named Format, so that it no longer shadows the function from the VBA standard library.
If you're using Rubberduck (an open-source VBIDE add-in project I manage), you can easily locate all references of the shadowing identifier:
The Rubberduck toolbar tells you when Format is referring to the correct function:
And you can easily locate all references to that as well, qualified or not - so it's easy to fully-qualify them wherever they are.
Rubberduck also makes it easy to refactor/rename the function, in a way that search/replace fails:
Coincidentally, a new code inspection is currently in works, specifically to locate shadowing identifiers like this.
As for the ByRef argument type mismatch, it seems your screenshot doesn't match with the code you posted, so anything is possible, but unless eqn is assigned in the body of that MakeEqn function (it should be returned, not assigned), then there's no need to pass it ByRef (implicitly or explicitly) - it can be passed ByVal (Rubberduck gives you an inspection result for that - and another for the implicit return type, and another for the implicit Public access modifier on both procedures, and several others for other issues in the code you posted).
更多推荐
发布评论