Управление ресурсами WPF (кисти и т. Д.) - PullRequest
11 голосов
/ 11 октября 2011

Обычно я добавляю то, что считаю конституциональными корневыми ресурсами, такими как фирменные цвета / кисти, шрифты и размеры, в сборку Dist.

Сборки Distrib предназначены дляСторонние разработчики получают доступ к нашим контрактам, интерфейсам и стилям брендинга.

Затем создаются более сложные ресурсы и объявляются «ближе», где они используются.

I 'Мы пришли к заявлению, которое выросло органически, ошибочно, случайно.Странно, что модули используют ресурсы из исполняемого проекта основного приложения, хотя модули не ссылаются на приложение.

Я предполагаю, что, поскольку они «импортируют» все ресурсы в App.xaml,они доступны для контекста конструктора psuedo-runtime.

Мой вопрос

Если это так, как MS спроектировал это для работы, я все время делал неправильно, управляяресурсы, как я делаю систему типов?

Спасибо

Люк

** ОБНОВЛЕНИЕ **

Итак, мне было указаноэти хорошо организованные ресурсы не подходят для WPF из-за серьезной проблемы с производительностью (как я обнаружил в большом приложении SL4, над которым я работал, но предполагал, что это был SL).

Предполагая, чтоУправление ресурсами таким высокоорганизованным способом все еще может быть выполнено с трюком или двумя, и что модульные системы часто должны объединять словари, я начал изучать использование решения SharedResourceDictionary Кристиана Мозера, но я получаю пробуТолько во время разработки:

System.IO.Packaging.PackUriHelper

The URI prefix is not recognized.
   at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
   at System.Net.WebRequest.Create(Uri requestUri)
   at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
   at System.Windows.ResourceDictionary.set_Source(Uri value)
   at CompanyName.Presentation.SharedResourceDictionary.set_Source(Uri value)

Похоже, он не понимает Uris пакета, что странно, поскольку SharedResourceDictionary просто вызывает исходную реализацию MS в ResourceDictionary и регистрирует схему URI пакета.статически тоже не помогает !!Grrr.

Так что мне нужно взломать, и второй вариант - втирать все в App.xaml и избегать слияния словарей.

Это означает меньше элементов управления / представлений и настройки дизайна.временный словарь в моей распространяемой библиотеке, который, я думаю, выполняет работу app.xaml, к которому у них нет доступа.

Я думаю, это имеет смысл.

Интересно?Скажите Microsoft

Это может быть для Silverlight, но я надеюсь, что ребята из WPF могут слушать, или, по крайней мере, это может исправить одну платформу - я добавил «идею» в UserVoiceсайт, за который можно проголосовать.

http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/2307678-fix-the-mergeddictionary-perf-problem

1 Ответ

1 голос
/ 11 октября 2011

Да, в App.xaml похоже, что он «должен» работать, хотя, как вы уже нашли, возможны и другие способы. Однако проблема производительности вызывает раздражение, и путь App.xaml также раздражает, потому что они не разрешаются во время разработки (по крайней мере, они не разрешают для нас, если они делают для вас, я хочу знать почему). *

Тем не менее, размещение их в App.xaml - единственная техника, о которой я нашел что-либо, приближающееся к «официальному» утверждению.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...