MVVM Light, TreeView ItemSource не обновляется - PullRequest
0 голосов
/ 24 апреля 2019

Я использую MVVM-Light.В моем XAML у меня есть следующая привязка в TreeView.

<TreeView Grid.Row="1"
                  ItemsSource="{Binding Model.Root.ChildPages, Mode=OneWay, UpdateSourceTrigger=PropertyChanged}" 

Свойство Model в VM выглядит следующим образом.

 public TreeModel Model
        {
            get { return model_; }
            set
            {
                Set(nameof(Model), ref model_, value);                   
            }
        }

TreeModel и TreeModel.Root являются ObservableObjects.TreeModel.Root.ChildPages - это ObservableCollection.

(Я на самом деле не изменяю привязанные в данный момент объекты, но я установил совершенно новую модель, чтобы фактически использовать наблюдаемые объекты, поскольку моя модель не должна иметь никакого значения, ноЯ думал, что стоит упомянуть)

При настройке моего свойства Model мой TreeView не обновляет / не показывает новую TreeModel.Насколько мне известно, функция Set () из MVVM Light должна вызывать RaisePropertyChanged () внутренне.

ViewModel, к которому привязывается View, получен из класса MyViewModelBase, производного от класса ViewModelBase MVVM Light.Свойство Model определено в классе MyViewModelBase.

Чего мне не хватает, почему представление не обновляется?Как ее решить?

При настройке свойства Model из конструктора ViewModels оно будет отображаться, как и ожидалось TreeView, это только последовательные вызовы извне элемента управления для свойства Model, которые не влияют на TreeView,Я отладил и подтвердил, что строка в установщике действительно вызывается

 Set(nameof(Model), ref model_, value); 

.

1 Ответ

0 голосов
/ 25 апреля 2019

Нашел решение проблемы. Dicrionary ресурсы не объединяются таким же образом, когда на них ссылаются пользовательские элементы управления второго уровня, как на уровне app.xaml. Так как мое представление было настроено на получение контекста данных из vmlocator, а контейнер IoC был локальным по отношению к vmlocator (должен, если нужно иметь возможность создавать несколько пользовательских элементов управления), представления второго уровня получили новые экземпляры VMLocator, а не родительский экземпляр , Следовательно, новый экземпляр также внедрил новую пустую модель, которая объясняла странное поведение.

...