是否在事件处理程序中始终需要投射发件人？

考虑下面的事件处理程序是否在事件处理程序中始终需要投射发件人？

Private Sub ProfileSelectCheckBox_CheckedChanged(sender As Object, e As EventArgs) Handles ProfileSelectCheckBox.CheckedChanged 
    ProfilesComboBox.Enabled = ProfileSelectCheckBox.Checked 
End Sub

在此处理程序，我不使用sender可言，但是我看到很多人在谈论铸造sender的格局。在我的情况下，我会最终得到一些尴尬的代码，因为处理程序没有将对象引用传递给ProfilesComboBox。

ProfilesComboBox.Enabled = DirectCast(sender, CheckBox).Checked

如果这个处理程序是另一个CheckBox在运行时添加，我最终会与一些断码的使用或不投，导致我相信这是最好的处理程序的定义的范围限制在一个方法内无论如何将它从外面隐藏起来，但也许这有点偏离主题。

在这个简单的例子中，我没有看到演员的需要。我的问题是，这是皱眉/不好的做法，还是很简单，让它通过？

来源

2014-01-23 djv

我不认为它是一个使用发件人的要求，更不用说投它了。如果你想要一个通用的事件处理程序，铸造可能会有所帮助，但是对于你的示例中的某些特定事物，它没有用。

然而，连接控件的更好方法可能是使用MVP模式，这会使样本中的行为更具可测性。

来源

2014-01-23 23:26:24 Andy

Private Sub Yadayada(...) Handles ProfileSelectCheckBox.CheckedChanged

不，已经很明显，发件人是谁了。毫无疑问，它是ProfileSelectCheckBox。因为这是您在句柄子句中命名的控件。在投送发件人时没有意义，不妨在代码中直接使用ProfileSelectCheckBox。

这是您写的事件处理程序的明显用法，许多事件处理程序就是这样。但并不限于此。句柄关键字接受多个事件源。你也可以写这样的：

Private Sub Yadayada(...) Handles ProfileSelectCheckBox.CheckedChanged, _ 
            UserSelectCheckBox.CheckedChanged

这对于有CheckChanged事件处理控件的事件处理程序。很显然，你现在对发件人参数更感兴趣，它可以让你分辨ProfileSelectCheckBox和发送相同CheckChanged事件的UserSelectCheckBox之间的区别。

您可以无限延伸，将更多的事件源添加到句柄子句中。或者，您可以在代码中使用AddHandler语句来执行此操作，而不使用Handles关键字。

这里的区别特征是，当您使用Winforms设计器时，不会发生这种情况。它发生在你编写你自己的代码而不是把它留给代码生成器。这是一个精神上的飞跃，这是一个非常重要的问题。它使你成为一个真正的程序员，不再遵守机器人为你生成代码。

恭喜并欢迎参加派对。

来源

2014-01-23 23:56:59

是否在事件处理程序中始终需要投射发件人？

回答

相关问题