是否在事件處理程序中始終需要投射發件人？

考慮下面的事件處理程序是否在事件處理程序中始終需要投射發件人？

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

是否在事件處理程序中始終需要投射發件人？

回答

相關問題