У меня есть библиотека управления WPF, которая добавляется в приложение Windows Forms. Мы хотим, чтобы элементы управления можно было локализовать, однако я не уверен, как ПОЛНОСТЬЮ сделать это без дублирования кода. Это то, чем я сейчас занимаюсь.
По сути, в приложении форм Windows перед запуском основного приложения я создаю экземпляр App.xaml, который находится в приложении форм (содержащий мои ссылки на мои ресурсы, которые также находятся в приложении форм). Это отлично работает во время выполнения.
Однако все мои пользовательские элементы управления имеют Content="{StaticResource SomeVariableName}", которые в конечном итоге остаются пустыми. Я могу исправить это, имея app.xaml и соответствующие словари ресурсов в моей библиотеке элементов управления, которые соответствуют таковым в моем приложении Windows Forms. Однако это дублированный код.
То, что я уже пробовал безрезультатно:
- Создайте экземпляр App.xaml, который находится в библиотеке пользовательских элементов управления, из моего приложения форм. Это не работает, потому что URI моих ресурсов ищет встроенный ресурс, а не мой локальный словарь ресурсов (тогда я мог бы просто скопировать файлы ресурсов из элемента управления в соответствующее место в моем приложении форм при сборке). Могу ли я использовать здесь DeferrableContent? Однако, насколько я мог найти в Интернете, об этом атрибуте и о том, как его следует использовать, не так много.
- I would like to use post builds for both App and dictionaries, however, the App instantiation is a static reference to a compiled App.xaml as far as I can tell. So, App.xaml must live within the form at least
- I did try to have a duplicated App.xaml with a post build moving the resourcedictionary.xaml. I figured that a duplicated app.xaml is ok since that is the driving force and you might not want to rely on one from the control anyway (which circles back and makes you wonder if you should then have the App.xaml in the control at all? Unless you want to allow a default that uses embedded resources....) That too failed saying it could not find the resource even though it was placed where the URI should have been pointing to. The decompiled code points to
Uri resourceLocater = new Uri("/WindowsFormsApplication3;component/app.xaml", UriKind.Relative);
- I did try to have a duplicated App.xaml with a post build moving the resourcedictionary.xaml. I figured that a duplicated app.xaml is ok since that is the driving force and you might not want to rely on one from the control anyway (which circles back and makes you wonder if you should then have the App.xaml in the control at all? Unless you want to allow a default that uses embedded resources....) That too failed saying it could not find the resource even though it was placed where the URI should have been pointing to. The decompiled code points to
Итак, есть ли способ позволить этому работать И иметь возможность просматривать значения компонентов по умолчанию во время разработки И избежать дублирования? Или в этом случае дублирование нормально? Если мой второй подпункт пули кажется нормальным (дублированный App.xaml со сборкой скопированных ресурсных словарей), как мне заставить его искать не элемент уровня компонента, а вместо этого один уровень файла?
Последний вопрос (и я могу опубликовать его отдельно, если необходимо), на который я только что обратил внимание. Мой App.xaml встраивается в код, поэтому в любом случае это не позволяет мне создавать новые ResourceDictionaries на лету. Есть какой-либо способ сделать это?
Последний вариант ... возможно, лучший? - Я планирую использовать код Андре ван Хирваарда в любом случае, так что я должен просто проверить наличие файла и добавить его как объединенный ресурс на лету? По сути, в моем пользовательском элементе управления должен быть один App.xaml, который ссылается на встроенный ResourceDictionary по умолчанию. И затем пусть код на лету ищет соответствующие локализованные ресурсы, которые могут быть относительными путями к файлам? Единственный недостаток, который я вижу здесь, заключается в том, что значение по умолчанию не может быть изменено на лету ... что я, вероятно, мог бы даже иметь такой вид в указанном месте (используя какое-то соглашение) и предпочел бы это встроенному?
О, и моя причина, по которой я не хочу встроенных ресурсов, заключается в том, что конечные пользователи могут добавлять / изменять новые локализованные ресурсы после развертывания сборки.
Я могу добавить код, если он поможет вам лучше это представить, просто дайте мне знать.
ОБНОВЛЕНИЕ
Теперь у меня возникла еще одна проблема со стилем, а не только с локализацией.
Вот пример одной из внутренних кнопок на одном из элементов управления:
<Button Style="{StaticResource GrayButton}"
Еще кое-что, что я пробовал / думал:
- Я не могу создать app.xaml (который никогда не будет использоваться) с ResourceDictionary, настроенным, поскольку ApplicationDefinitions не разрешены в проектах библиотеки. Я мог бы встроить это в ресурсы элемента управления, но тогда это всегда будет иметь приоритет над любыми ресурсами уровня приложения, и я потеряю настраиваемость.
Вот пример подключения, который на самом деле звучит так Я ищу, но это не дает реального решения этой проблемы.
Решение (помимо самого верха ... которое не работает), которое я могу придумать, могло бы сработать (и еще не пробовать), также кажется большим трудом для чего-то, что, как мне кажется, должно быть простым. Но я мог бы создать некоторые свойства зависимостей в элементе управления, к которым я могу привязаться, а затем позволить им переопределить проект, который будет использовать этот элемент управления. Как я уже сказал, для довольно простого запроса это кажется большим трудом :). Это вообще сработает? И что еще более важно, есть ли лучшее и более простое решение, которое мне не хватает?
