代码之家  ›  专栏  ›  技术社区  ›  Dave M

WPF“已更改”事件

  •  0
  • Dave M  · 技术社区  · 15 年前

    我使用WPF已经有一段时间了,我已经非常习惯了许多(对于未初始化的)特性:XAML、绑定、模板、触发器等,但我似乎无法完全掌握事件系统。从一开始就让我紧张的是,被称为“已更改”事件(即ListBox.SelectionChanged或TextBox.TextChanged)的事件在它们引用的实际属性发生更改之前触发。

    99%的时间我只想响应用户输入事件,看看新值是什么。在更新控件以取消更改或保存以前的值或其他内容之前,我很少需要响应。

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

    是的,我知道我可以使用事件参数来确定新值是什么,但是这非常烦人,通常需要大量的强制转换。

    当此代码触发时,是否要求过多:

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

    该mytextbox.text具有text属性的新值。我只是疯了吗?还是我错过了什么?

    2 回复  |  直到 15 年前
        1
  •  1
  •   HCL    15 年前

    如果订阅,示例中的文本框将具有新值 TextChanged . 有个活动 PreviewTextInput . 这个会像你描述的那样,你不喜欢。

    阿尔索 SelectionChanged 顾名思义。这里唯一要注意的是,如果你有一个( SelectedItem )它的目标是另一个异步生成的控件,例如TreeView控件或itemsControl派生,请求目标属性时可能会有延迟。但这似乎不是你描述的问题。

        2
  •  0
  •   Rob Perkins    15 年前

    这种行为可以让你扭转变化,额外的灵活性也伴随着这个痛点。

    我感觉到你的痛苦,但我觉得没什么好做的。将代码修改为:

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

    …这只是稍微不太清楚,但仍然在一条线上。

    或者,如果你偏执于此:

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

    我想很多人会批评在后面的XAML代码中选择事件处理,而赞成MVVM模型,但这是您的设计决策,而不是他们。