Question

我已经使用WPF一段时间了，我已经习惯了许多（相当令人生畏的不熟悉的）功能：XAML，Binding，模板，触发器等。但我似乎无法忍受完全掌握事件系统。从一开始就让我紧张的事情就是被称为“已更改”事件的事件（即ListBox.SelectionChanged或TextBox.TextChanged）在它们引用的实际属性被更改之前触发。

99％的时间我只想回复用户输入事件并查看新值是什么。在更新控件以取消更改或保存以前的值或其他值之前，我实际上很少需要响应。

当变化尚未完全发生时，将这些事件称为“已更改”事件对我来说毫无意义，它仍在发生。至少对我来说，将这些事件称为“改变”事件会更有意义，然后在所有事件更新之后，“更改”事件将会触发。

是的我知道我可以使用事件args来确定新值是什么，但这非常令人讨厌并且通常需要大量的投射。

当此代码触发时，是否要求太多：

void myTextBox_TextChanged(object sender, TextChangedEventArgs e)
{
     DoSomething(myTextBox.Text);
}

myTextBox.Text具有text属性的NEW值。我只是疯了吗？或者我错过了什么？

Answer 1

如果您订阅TextChanged，示例中的文本框将具有新值。有一个事件PreviewTextInput。这个将按你所描述的那样行事，你不喜欢。

SelectionChanged也就是顾名思义。这里唯一需要注意的是，如果你有一个Binding（SelectedItem）并且这个目标是另一个构建async的控件，例如TreeView控件或ItemsControl-derivations，那么可能有一个延迟申请目的地财产。但这似乎不是你描述的问题。

Answer 2

这种行为可以让你扭转这种变化，而这种痛点会带来额外的灵活性。

我感觉到你的痛苦，但我认为还有很多工作要做。将代码修改为：

DoSomething(((TextBox)sender).Text);

......只是稍微不那么明确，但仍然在一条线上。

或者，如果你对它很偏执：

       TextBox t = sender as TextBox;
       if (t!=null) DoSomething(((TextBox)sender).Text);

我想很多人会批评后面的XAML代码中的事件处理选择，支持MVVM模型，但这是你做出的设计决定，而不是它们。

WPF'改变了'事件

2 个答案: