我们有一个用 VB6 编写的(非常)Legacy 应用程序(15 岁？)。
应用程序包含一个间隔为 300 毫秒的计时器。计时器滴答时调用的 Sub 执行一批代码，这些代码与一些 SQL 服务器对话，打印一些标签等等。
当一切正常时，此 Sub 在 5 毫秒到 10 毫秒内执行 - 即在下一个计时器间隔发生之前 - 但在下一个滴答之前它也会浪费 290 毫秒。
我们需要让这个应用程序更快一点，一个选择是将间隔更改为 1 毫秒 - 在我们这样做之前，我只想确认计时器是否会中止间隔(也就是 - 完全忽略tick) 如果前一个间隔仍在执行 - 或者它会开始构建对 sub 的调用堆栈，导致一段时间后挂起？ (我当然假设所有 ticks 都在与 gui 相同的线程中执行——因此我们需要在每次 tick 之后使用 DoEvents 以确保 UI 不会挂起。)
我已经尝试研究这个问题，但事实证明要找到有关旧 VB6 计时器的可靠信息非常棘手。
我们确实计划使用线程和后台工作线程在 .net 中重写这个 - 这只是我们正在研究的短期修复。
最佳答案
这不是 VB6 计时器的工作方式，Tick 事件只能在您的程序空闲并停止执行代码时触发。技术术语是“再次泵送消息循环”。 DoEvents 泵消息循环。这是一个非常危险的函数，因为它不仅分派(dispatch)计时器的 Tick 事件，而且分派(dispatch)所有 事件。包括让用户关闭窗口或在功能仍在忙于执行时再次启动功能的功能。不要使用 DoEvents，除非你喜欢危险地生活或彻底了解 its consequences .
您将其速度提高 300 倍的努力也注定要失败。对于初学者，您无法获得 1 毫秒的计时器。 Windows 上的时钟分辨率不够高。默认情况下，它每秒递增 64 次。因此，您可以获得的最小间隔是 16 毫秒。其次，您不能指望让慢速代码任意变快，至少因为 Tick 事件不会叠加。
您可以要求 Windows 提高时钟分辨率，这需要调用 timeBeginPeriod()。这不是你应该考虑的事情。如果这真的有效，那么当您每毫秒访问该服务器时，您一定会得到一个非常交叉的数据库管理员的访问，他拿着一个钝器。
关于multithreading - 如果前一个滴答声仍在运行，则执行旧版 VB6 计时器滴答声堆栈或跳过，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16234678/