我阅读了这篇出色的文章Comparing the Timer Classes in the .NET Framework Class Library并得出结论,我可以用它做的任何事情都Windows.Forms.Timer
可以做得更好Timers.Timer
- 然后是一些.
所以想到的明显问题是:为什么要Windows.Forms
提供 Timer?
旧版(向后兼容性)支持?
其他?
我阅读了这篇出色的文章Comparing the Timer Classes in the .NET Framework Class Library并得出结论,我可以用它做的任何事情都Windows.Forms.Timer
可以做得更好Timers.Timer
- 然后是一些.
所以想到的明显问题是:为什么要Windows.Forms
提供 Timer?
旧版(向后兼容性)支持?
其他?
的主要方便之Windows.Forms.Timer
处在于它的事件在 UI(Winforms)线程上触发。如果您的计时器事件执行 UI 操作,它可能是最简单的选择(而不是调用Control.Invoke/BeginInvoke
或SynchronizationContext.Post/Send
在您的所有事件中)。
这些Windows.Forms.Timer
事件在 UI 线程上被调用,因此您可以直接从事件处理程序更新 UI,这通常不是这种情况Timers.Timer
(因为您会遇到跨线程访问冲突异常)。
而且,正如@Robert Harvey回答的那样,它也有设计师的支持。
Windows.Forms 的优点之一是它在 GUI 的同一线程中运行,并且在访问 Form 控件时不会出现跨线程异常。
Windows.Forms.Timer 具有设计器支持。因此它的行为与任何其他 Winforms 组件一样(例如,您可以将它拖到表单上,它是 Controls 集合的一部分,等等)。
类引发的计时器事件System.Windows.Forms.Timer
与 Windows 窗体应用程序中的其余代码同步。这意味着正在执行的应用程序代码永远不会被此计时器类的实例抢占(假设您不调用Application.DoEvents
)。类触发的事件Windows.Forms.Timer
与您的 Winform 控件兼容;您可以安全地与他们互动,而无需致电Invoke()
.
该类System.Timers.Timer
是一个基于服务器的计时器,专为在多线程环境中使用而设计和优化。可以从多个线程安全地访问此计时器类的实例。尽管Invoke()
在技术上需要与 Winforms 交互,但 Timer 类确实提供了一个SynchronizingObject
属性,您可以将要与之安全交互的 Windows 窗体附加到该属性。
更多信息:http: //msdn.microsoft.com/en-us/magazine/cc164015.aspx
好吧,我认为答案是它们是两种完全不同类型的计时器。这Windows.Forms.Timer
是一个单线程应用程序计时器,非常适合存在于客户端运行应用程序上的计时器。
Timer 用于以用户定义的时间间隔引发事件。此 Windows 计时器专为使用 UI 线程执行处理的单线程环境而设计。它要求用户代码具有可用的 UI 消息泵,并且始终从同一个线程操作,或者将调用编组到另一个线程。
相比之下,这Timers.Timer
是一个基于服务器的计时器,更适合 Windows 服务。
Timer 组件是一个基于服务器的计时器,它允许您指定在应用程序中引发 Elapsed 事件的重复间隔。然后,您可以处理此事件以提供常规处理。例如,假设您有一台关键服务器必须每周 7 天、每天 24 小时保持运行。您可以创建一个使用 Timer 定期检查服务器并确保系统正常运行的服务。如果系统没有响应,该服务可能会尝试重新启动服务器或通知管理员。
您可以找到他们的文档并阅读 Microsoft 的摘录和更多内容。
并不是说永远不应该使用或始终使用一个,而是服务于两个不同的目的。
我相信它是用于 winform 设计器集成的,因为您可以将其拖到表单上,单击它并在属性窗格中设置其属性。