OneWayToSource Binding кажется сломанной в .NET 4.0

Question

OneWayToSource Binding кажется сломана в .NET 4.0

У меня есть этот простой кусок Xaml

<StackPanel> 
    <TextBox Text="{Binding TextProperty, Mode=OneWayToSource}"/> 
    <Button/> 
</StackPanel> 

И мой код позади выглядит так

public MainWindow() 
{ 
    InitializeComponent(); 
    this.DataContext = this; 
} 
private string m_textProperty; 
public string TextProperty 
{ 
    get 
    { 
     return "Should not be used in OneWayToSource Binding"; 
    } 
    set 
    { 
     m_textProperty = value; 
    } 
} 

В .NET 3.5 это работает, как вы могли бы исключить. Поместите текст в TextBox, нажмите Tab, чтобы сделать его потерять фокус, и TextProperty обновления с любым текстом, который был введен в TextBox

В .NET 4.0, если ввести текст в TextBox, а затем нажмите Tab, чтобы потерять Focus, TextBox возвращается к значению для TextProperty (что означает «Нельзя использовать в привязке OneWayToSource»). Это перечитывание предназначено для привязки OneWayToSource в .NET 4.0? Я просто хочу, чтобы TextBox нажал его значение на TextProperty, а не наоборот.

Update
Добавление Bounty на этот вопрос, как это стало мэром неудобством в моем проекте, и я хотел бы знать причину, по которой это изменилось. Кажется, что get вызывается после того, как Binding обновил источник. Является ли это желательным поведением для привязки OneWayToSource в .NET 4.0?

Если да

• Что была проблема с тем, как он работал в 3.5?
• В каких сценариях это новое поведение лучше?

Или это это на самом деле ошибка, что мы можем надеяться получить устранен в следующей версии?

Answer 1

блог Карла Shifflett в и @ ответ Simpzon уже рассмотрим, почему именно они добавили эту функцию, и почему это не является проблемой для свойств, которые всегда получают то, что было установлено. В вашем собственном коде вы всегда используете промежуточное свойство, которое имеет надлежащую семантику для привязки и использует внутреннее свойство, которое имеет семантику, которую вы хотите. Я бы назвал промежуточное свойство «блокирующим», потому что он блокирует getter от вашего внутреннего свойства.

Но в случае, если у вас нет доступа к исходному коду для объекта, на который вы устанавливаете свойство, и вы хотите использовать старое поведение, вы можете использовать конвертер.

Вот блокирующий преобразователь с государством:

public class BlockingConverter : IValueConverter 
{ 
    public object lastValue; 

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
     return lastValue; 
    } 

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
     lastValue = value; 
     return value; 
    } 
} 

и вы можете использовать его для примера, как это:

<Grid> 
    <Grid.Resources> 
     <local:BlockingConverter x:Key="blockingConverter" x:Shared="False"/> 
    </Grid.Resources> 
    <StackPanel> 
     <TextBox Text="{Binding TextProperty, Mode=OneWayToSource, Converter={StaticResource blockingConverter}}"/> 
     <Button Content="Click"/> 
    </StackPanel> 
</Grid> 

Заметим, что, поскольку преобразователь имеет состояние вам нужен отдельный экземпляр каждый раз, когда используется ресурс, и для этого мы можем использовать атрибут x:Shared="False" ресурса.

Answer 2

Ошибка, определенно.

, если это «особенность», это очень плохо один ...

, кажется, они добавили вызов функции Get() после множества() выполняется, даже в режиме OneWayToSource. .. может кто-нибудь объяснить почему?

также, спасибо за указание на это, он объясняет проблему, я имел, так как я модернизировал свой проект .NET 4.0 и что я никогда не мог объяснить до сих пор ...

только побочное замечание: у меня есть решил это, используя свойства зависимостей в конце.

Answer 3

Это действительно по дизайну. Как правило, это не должно беспокоить, но, по вашему мнению, реализация вашей собственности, по крайней мере, нестандартная. Getters and setters (accessors) должны действительно не намного больше, чем получать и устанавливать, и каждый get должен соответствовать последнему соответствующему набору. (извините, нет источника для этого, это то, что мы назвали хорошим гражданством во всех командах разработчиков, в которых я был).

Более подробно о функции здесь: http://karlshifflett.wordpress.com/2009/05/27/wpf-4-0-data-binding-change-great-feature/

Answer 4

Является ли это желательным поведением для привязки OneWayToSource в .NET 4.0?

Да. Это делается для способности разработчика изменять предоставленную стоимость без неуклюжих конвертеров.

В чем была проблема с тем, как он работал в версии 3.5?

Нет проблем. Способ, которым он работал в 3.5, не позволял исправлять предоставленные значения.

В каких сценариях это новое поведение лучше?

Когда вам нужно исправить предоставленные значения. Если вам это не нужно, тогда вы должны просто написать правильный getter и setter.

public string TextProperty 
{ 
    get; 
    set; 
} 

Однако, как я могу видеть, меняя UpdateSourceTrigger к «PropertyChanged» сохраняет значения от того перечитать (так что вы можете оставить старую декларацию собственности):

<StackPanel> 
    <TextBox Text="{Binding TextProperty, Mode=OneWayToSource, UpdateSourceTrigger=PropertyChanged}"/> 
    <Button/> 
</StackPanel> 

    private string m_textProperty; 
    public string TextProperty 
    { 
     get 
     { 
      return "Should not be used in OneWayToSource Binding"; 
     } 
     set 
     { 
      m_textProperty = value; 
     } 
    } 

Answer 5

Это совершенно ясно ошибка. Кажется, что кто-то сообщил хотя бы один раз. https://connect.microsoft.com/VisualStudio/feedback/details/612444/onewaytosource-broken-in-net-4-0

Я согласен со многими другими, что один путь должен быть в один конец.

Мой сценарий сложный, и функциональность, измененная между версиями каркаса, вызвала у меня настоящую головную боль.

У меня есть текстовое поле, связанное с объектом. У меня есть конвертер, который меняет формат на лету. EG: Я ввожу EU5 в текстовое поле, свойство получает EU005. У меня есть набор привязки, который запускается при изменении свойства, поскольку мне нужно выполнять поиск в ViewModel по типу пользователя.Новая реализация изменяет значение текстового поля по мере ввода. Поэтому, если я хочу набрать EU512, я не мог бы легко, так как текст текстового поля продолжал бы меняться.

Я пробовал много вещей - Явное связывание (где вы решаете, когда обновлять и каким образом.) У этой проблемы есть такая же проблема. Если я скажу, UpdateSource, он делает, но также затем перечитывает свойство и изменяет цель тоже.

Я попробовал OneWayToSource и имел ту же проблему. Я не нашел возможности обойти это без внесения раздражающих изменений в мою виртуальную машину. Единственный другой способ - удалить привязку в этом поле и начать стрелять событиями, которые были бы ужасными.

Если MS сделала привязку так, как она логически названа, моя проблема исчезнет. Даже свойство на привязку к отказу от реализации .net4 и вести себя как 3.5 будет работать для меня.

У кого-нибудь есть предложения по поводу того, как я могу обойти это?

Answer 6

У меня был вариант этой проблемы для двусторонней привязки. Я понимаю, что это не совсем то же самое, что обсуждаемая проблема, но этот ответ поднялся во время поиска, и это привело к моему решению. Надеюсь, кто-то сочтет это полезным.

Мое решение блокирует повторное чтение свойства резервного копирования, но обновит пользовательский интерфейс, когда он будет изменен каким-либо другим источником. Я основывал свое решение на блокирующем конвертере в ответе Рика Слэдки.

Он просто добавляет чек конвертеру, чтобы увидеть, будет ли поле lastValue конвертировать в одно и то же хранилище. Если нет, значение хранилища резервной копии должно быть изменено с другого источника, и пользовательский интерфейс должен быть обновлен.

public class MyConverter : IValueConverter 
{ 
    public object lastValue; 

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
     if (LastValue != null && MyConvertBack(LastValue).Equals(value)) 
      return lastValue; 
     else 
      return MyConvert(value); 

    } 

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) 
    { 
     lastValue = value; 
     return MyConvertBack(value); 
    } 

    private object MyConvertBack(Object value) 
    { 
     //Conversion Code Here 
    } 

    private object MyConvert(Object value) 
    { 
     //Conversion Code Here 
    } 
} 

В моем конкретном USECASE для этого я имел длину и размер суффикс, хранящийся в текстовом поле (10м, 100мм и т.д.). Преобразователь проанализировал это на двойное значение или добавил суффикс (в зависимости от направления преобразования). Без конвертера он добавит суффикс для каждого обновления текстового поля. Попытка ввести «10» приведет к «1m0», так как конвертер будет работать после первого нажатия клавиши.