Алексей КЧитательXНо, теперь есть другая проблема. В этом дереве представлены только видимые элементы.Само собой.
ЧитательXТ.е. если дерево свернуто, то виден только корневой TreeViewItem.
Но, если мне нужно программно найти узел внутри дерева и развернуть эту веточку.
Как искать такой DependencyObject? Его в дереве нет.Надо идти с корня дерева и разворачивать по очереди всех "родителей" целевого элемента дерева.
Когда дело доходит до такой ручной работы, уже проще кажется MVVM .

Ищите по "Expand all the way up to the root" - как сделать авторазворачиваемые "отсюда и до корня". Как сделать "отсюда и все ветки до конца" - думаю, как-то подобным образом же.

На самом деле без MVVM проще только для самых простых примеров, когда, как вы сказали, "чтобы на совсем простом примере разглядеть как работает TreeView". Когда примеры становятся сложнее, то принцип работы меняется. Без MVVM вам придётся писать кучку методов по обходу и разворачиванию-сворачиванию веток. Где эти методы будут? В воздухе висеть? В некоей библиотеке "хелперов для тривью"? А в MVVM у вас вся логика по работе с вашим тривью инкапсулирована в моделях представления будет.

Алексей Кuser7320Когда дело доходит до такой ручной работы, уже проще кажется MVVM .Алексей КДа и зачем всё это? Чем здесь MVVM не угодил?
ЧитательXНа счет MVVM. Пока в нем не работаю...
Так я к тому сказал, что проще будет перейти на MVVM. Объём кода в MVVM такой же или меньше, зато структурированности больше. MVVM хуже только для самых простых приложений - там он действительно выглядит ненужным нагромождением монструозных конструкций.

Если что, MVVM можно организовать и для отдельно взятой сущности или участка программы. Можно проще ещё сделать - сделать только VM и V. Собственно, WPF только вокруг ВМ и В и построен. Я так написал одно приложеньице, когда надо было к готовой логике интерфейсик приделать.

Алексей КРазумнее рассматривать класс TreeViewItem как часть ViewModel. Тогда и концепция MVVM применяется и все имеющиеся возможности WPF используются.
Там когда привязку делаешь, TreeViewItem автоматом генерится как обёртка над привязываемым значением из модели представления, вроде.

Я, правда, не понял, почему у ТСа не отрабатывается событие SelectedItemChanged. У меня через MVVM к тому же событию команда привязана и всё отрабатывается, когда я кликаю на невыбранный айтим.

user7320Алексей КРазумнее рассматривать класс TreeViewItem как часть ViewModel. Тогда и концепция MVVM применяется и все имеющиеся возможности WPF используются.
Там когда привязку делаешь, TreeViewItem автоматом генерится как обёртка над привязываемым значением из модели представления, вроде.
Я к тому, что TreeViewItem больше относится к генерации представления. Т. е. если охота вручную TreeViewItem добавлять, то в MVVM это лучше делать в коде поддержки - этакая вью-вью-модель.

Алексей Кuser7320пропущено...

Я к тому, что TreeViewItem больше относится к генерации представления. Т. е. если охота вручную TreeViewItem добавлять, то в MVVM это лучше делать в коде поддержки - этакая вью-вью-модель.Я о том, что не надо самому писать аналог класса TreeViewItem со свойствами Content, IsExpanded, IsSelected и т. п.
Тогда по этой логике и CollectionView может заменить коллеции из VM?

Ведь "аналог" класса TreeViewItem во VM не просто свойства такие содержит, но и логику по ленивой загрузке и прочую логику. Например, отрисовку крестика ("можно развернуть"), если айтим содержит потомков, или другого рисунка, если не содержит. Много чего ещё. А как "расширить" подобной функциональностью TreeViewItem?

Алексей Кuser7320Ведь "аналог" класса TreeViewItem во VM не просто свойства такие содержит, но и логику по ленивой загрузке и прочую логику. Например, отрисовку крестика ("можно развернуть"), если айтим содержит потомков, или другого рисунка, если не содержит. Много чего ещё. А как "расширить" подобной функциональностью TreeViewItem?Я не говорил, что модель и HierarhicalDataTemplate не нужны. Всё что нет в TreeViewItem должно быть в модели. Но не надо пихать в модель то что есть в TreeViewItem, только если для этого есть особые причины.
А где я пихаю? Я привязываю. У VM IsExpanded и у V IsExpanded - привязал. Также как у VM текстовое поле и у V тоже есть TextBox - тоже привязал.

Алексей Кuser7320Я привязываю. У VM IsExpanded и у V IsExpanded - привязал.А зачем:
1. Добавить свойство в VM.
2. Добавить привязку данных V <=> VM.

Может проще дать логике ссылку на TreeViewItem? Разумеется, это не единственное решение, просто предлагаю об этом подумать. :-)
Вы можете привести пример?.. Хотя, если это связано с вашей работой "Простое решение", где у вас предполагается настолько тесная связь между V и VM, что VM ссылается на V (а не наоборот, как в классике), то не надо. ))

Если вы дадите ВМ ссылку на В, то останется ли возможность привязывать несколько В к одной ВМ? Каким образом?

И что станет со всеми этими словами "меньше связность - лучше тестирование"?

Алексей Кuser7320Если вы дадите ВМ ссылку на В, то останется ли возможность привязывать несколько В к одной ВМ? Каким образом?Конечно, нет. Если требуется такая возможность - используй классический MVVM на здоровье. :-) Но часто ли это надо?
Ладно, дайте ссылку, где у вас пример с привязкой ВМ ко В. Или лучше словами простыми опишите, как вы это делаете.

Я вот примерно такой подход применил, когда надо было несколько модальных окон друг на друге показать:



И для таких штук можно много вложенностей детей сделать.

Алексей К Тут описана работа с окнами. Но я не пойму вопроса. Модели окон связываются наиболее удобным способом: свойствами, событиями или ещё как. В чём интрига? :-)
Да ни в чём. Я просто сделал не по правилам, и боялся, что кто-нибудь увидит и скажет ай-яй-яй. ))

Ну, у вас примерно как у меня, только я сразу в DataContext данные пихаю, а не в метод-хелпер.

А когда вы делаете "установку содержимого окна" через




вы можете потом из этого content свойства раскидать по привязкам в замл-разметке этого окна? Без установки DataContext?

И это, вызов нескольких диалоговых окон одно из другого у вас нормально пройдёт?