是不是一味地使用InvokeRequired只是不好的做法？
我是一名新手程序员，所以我可能在这里完全弄错了，但是这个问题让我更加困惑。
这实际上是这个问题的后续行动。
接受的答案是，您必须调用InvokeRequired以避免一些开销，因为您可能已经在UI线程上运行。
理论上，我同意它可以节省一些时间。 经过一些测试后，我发现使用Invoke的时间大约是正常调用操作的两倍（测试类似于设置标签文本n次，或者在RichTextBox中放置一个非常非常大的字符串）。
但！ 然后有练习。
MSDN文档说：
此属性可用于确定是否必须调用invoke方法，如果您不知道哪个线程拥有控件，这可能很有用。
在大多数情况下，您确实知道何时尝试从另一个线程访问控件。 实际上，我能想到的唯一情况是，从一个可以被线程X调用的方法以及所有者线程访问控件时。 这对我来说是一个非常不可能的情况。
即使你真的不知道哪个线程试图操纵控件，也有一个事实是UI线程不必经常更新。 对于您的GUI，25-30 fps之间的任何内容都应该没问题。 在UI控件中进行的大多数更改所花费的时间远远少于毫秒。
因此，如果我理解正确，则必须检查是否需要调用的唯一情况是，当您不知道哪个线程正在访问控件时以及GUI更新需要超过大约40毫秒才能完成时。
然后我在https://programmers.stackexchange.com上询问了这个问题的答案。 这表明，当您不需要它时，您不应该忙于过早优化。 特别是如果它牺牲了代码的可读性。
所以这让我想到了一个问题：当你知道一个不同的线程访问一个控件时，你不应该只使用invoke，并且只有当你知道你的UI线程可以访问那段代码并且你发现它应该运行得更快，那么你应检查是否需要调用？
PS：在校对我的问题之后，听起来真的像我在咆哮。 但实际上我只是好奇为什么InvokeRequired似乎被许多经验丰富的程序员过度使用。
你在这里断章取义。 你链接的第一个问题链接了另一个问题，特别是关于编写一个线程安全的方法来访问UI控件。
如果您不需要对UI控件进行线程安全访问，因为您知道不会从其他线程更新它，那么您当然不应该使用此技术。 只需更新UI控件，而无需使用InvokeRequired或Invoke 。
另一方面，如果调用始终始于UI线程以外的线程，则只需使用Invoke而不先检查InvokeRequired 。
这导致三个简单的规则：
- 如果仅从UI线程更新控件，则既不使用
InvokeRequired也不使用Invoke - 如果仅从UI线程以外的线程更新控件，请仅使用
Invoke。 - 如果从UI线程和其他线程更新控件，请将
Invoke与InvokeRequired结合使用。
在实践中，人们倾向于从外部线程和拥有线程调用相同的方法。 通常的模式是方法本身确定线程是否是拥有线程。 如果是，则执行后续代码。 如果不是，则此方法使用Invoke自己的self。
这样做的一个好处是它使代码更紧凑 ，因为你有一个与操作相关的方法而不是两个。
另一个也许更重要的好处是它减少了引发跨线程exception的可能性。 如果两种方法在任何时候都可用，并且两个线程都可以选择这两种方法中的任何一种，那么就有可能出现看似合法的方法调用exception。 另一方面，如果只有一种方法适应这种情况， 它提供了一个更安全的界面 。
上述就是C#学习教程：是不是一味地使用InvokeRequired只是不好的做法？分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/cdevelopment/985721.html