EventSetters в теме ResourceDictionary

Question

MSDN говорит о установщиках событий:

Установщики событий нельзя использовать в стиле, который содержится в словаре ресурсов темы. Это связано с тем, что словарь ресурсов темы во время выполнения часто представляет собой потерянные двоичные файлы XAML (BAML) и не имеет какой-либо определенной области действия, где может существовать сопровождающий код, определяющий обработчики.

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

у ресурса xaml не может быть кода за файлом, их обычно называют "свободный xaml". Вы можете прочитать об этом в MSDN о EventSetter.

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

С другой стороны, добавление установщика событий в стиль в том же словаре ресурсов приводит к исключению.

Я столкнулся с особым случаем, когда это работает?

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

Мой вопрос сводится к:

Что именно подразумевается под заявлением MSDN о том, что словарь ресурсов темы часто представляет собой потерянный двоичный XAML - как часто, при каких именно обстоятельствах?

Answer 1

Это означает, что он компилируется сам по себе, а не с кодом позади или внутри пространства имен.

Или, другими словами, в свободном xaml-файле отсутствует фрагмент кода, он может быть считан из базы данных, например, как текст, или сгенерирован на лету, как текст, и загружен без какой-либо кодифицированной ассоциации.

Что касается погоды, это веская причина или нет. Это зависит от каждого разработчика, но именно это означает свободный xaml.

Редактировать:

В ответ на ваш комментарий я бы предположил, что они конкретно ссылаются на ресурсы и стили, так как это наиболее распространенные "свободные файлы", и, как правило, большинство людей не поддерживают их с помощью файла кода. Лично я рассматриваю это как выход. Они могли бы легко добавить атрибут Loose=True и решить эту проблему.

На самом деле проблема не в объеме потерянных файлов или в частоте их использования, а в том, что было создано правило для компенсации отсутствующей функции. Было бы намного проще, если бы они просто сказали, что вы не можете делать x,y,z, потому что мы не создали его поддержку, вместо того, чтобы сказать, что это из-за произвольного числа свободных файлов xaml.