Создал я некое свойство зависимости (пусть будет присоединяемое, в данном случае неважно)



Работает, в том числе байндинг.
Через некоторое время захотел я в это свойство добавлять несколько элементов. Создал специальную коллекцию:




В MyItemCollection (кстати, наследник Freezable) реализовал вручную интерфейс IList (ну чтоб все операции с коллекцией оставить под контролем, а именно, для добавляемых/удаляемых элементов выполнять определенные операции). Интерфейса IList достаточно для того, чтобы при разборе XAML вложенные элементы попали в коллекцию.

Эта конструкция работает, но не совсем. Свойство SomeProperty заполняется нормально, а вот Binding не работает, то есть DataContext не виден для элементов коллекции.

Начал копать - выясняется, что для такиx случаев (вложенных коллекций свойств) применяется/предназначен FreezableCollection<T> . Однако, если глянуть исходники , выясняется, что FreezableCollection<T> тупо наследует Collection<T>, не имплементирует никаких новых интерфейсов. Так почему же тогда в случае FreezableCollection<T> элементы MyItem попадают в логическое дерево, а в моем случае - нет? Неужели анализатор XAML тупо смотрит на тип объекта, а не на реализуемые им интерфейсы - это по меньшей мере странно.

Нет, ну можно, конечно, реализовать MyItemCollection на базе FreezableCollection<T> и написать обработчик CollectionChanged для внутренних нужд. Но все-таки хочется понять, как это работает. Может кто-нить объяснить простыми словами?

Алексей КПрисоединяй через Interaction Behaviorsнет смысла, если работают штатные средства.
Вопрос не в том, чтобы заставить работать (как минимум, один путь есть), а понять как это работает.
Поиск DataContext осуществляется вверх по логическому дереву. Свойство - вроде как не часть логического дерева. То есть байндер по идее заглядывает сначала в собственный элемент, потом ищет выше. Но в случае коллекции сами элементы имеют родителем коллекцию и как бы оторваны от контекста элемента (и логического дерева). Алексей Кили посмотри как там сделана эта коллекция.я дал ссылку на исходник - там ничего нет внутри, добавляется только признак frozen, не описанный никакими интерфейсами.

Алексей К Тут про это пишут.спасибо, несколько яснее стало, как работает Freezable, путем введения пары терминов, которые раньше не встречались, а именно "special inheritance tree" и "inheritance context". Но этот момент я раньше воспринимал "как есть", то есть делал нужные классы наследниками Freezable.
Но в данном вопросе не освещено, как это special inheritance tree работает с FreezableCollection, учитывая, что FreezableCollection не имеет ничего интересного относительно обычной коллекции

Алексей КОстаётся гадатьну, в общем, погадал.

Сделал копию FreezableCollection - с ней не работает, с оригинальной FreezableCollection работает. Значит построитель пресловутого special inheritance tree ориентируется именно на конкретный класс FreezableCollection, а не на какие-то интерфейсы.

Ой, чет-я тупанул неслабо. Это не та FreezableCollection - я не те исходники смотрел, не ожидал, что их две может быть в .NET и даже не посмотрел неймспейс. Вот правильная ссылка .

Там есть
это как раз о многом говорит

Однако OnInheritanceContextChangedCore по-видимому есть только 4.5.1, но работает и без него.

FreezableCollection набита реализацией нескольких интерфейсов, плюс проверки на правильный поток, плюс всякое, наверняка необходимое презентационному ядру поведение.

Из упрямства все-таки нашел, что минимально нужно сделать для того, чтобы работал свой IList (то есть именно FreezableCollection все-таки не обязателен для презентационного ядра, но класс должен наследовать Freezable), а именно:

FreezableCollection в этом месте реализует обход коллекции. Также, для каждого присоединяемого элемента надо выполнить
, причем неважно, до или после того, как сама коллекция будет присоединена к вышестоящему свойству.