Как стать автором
Обновить

Комментарии 18

Классная штука, я использовал её для собственной валидации при связывании(binding). Правда есть вещи которые не смог тогда «победить». Сейчас вспомнил про IValueConverter на данном MarkupExtension, который нельзя использовать в markup. Например:
(сорвалось, простите)

/>
(тяжело овладеть тегами :( )

Button Content="{SelfBinding Path=MyPath, Conveter={StaticResource MyConverter}}"
Да, вы здесь правы, к соажлению, не работает. Сделал все так же как и в стандартном биндинге, при компиляции выдает ошибку. Буду дальше искать пути решения
Я помню пытался через рефлектор посмотреть, как организуется класс Binding, на наличие каких-нибудь метаданных на Converter — безуспешно.
Тож на этом остановился. Наверное гденить в дебрях дот нет есть список всех встроенных расширений и там есть специальный дерективы… :D
Нашел немного бубенчатый путь:

Button
Button.Content
local:SelfBinding Path=«Foreground»
local:SelfBinding.Converter
local:ValueConvrter
local:SelfBinding.Converter
local:SelfBinding
Button.Content
Button
Это я знал, но это раздувает код и не очень красиво.
>например мы так соорудили поддержку мультиязычности

А что в стандартной поставке WPF нету мультиязычности? О.о
Есть, но это такие пляски с бубнами. Нужно создать ресурс, потом его с помощью тулзы преоразовать в cvs, перевести, снова в ресурс собрать (так написано в тутариале), а затем еще и перекомпилить! прогу.
У нас все через единсвенный xml файл работает
Перекомпилить прогу чтобы добавить локализацию? О.о
Черт а ведь шёл 2010ый год…
Разве нельзя потом эти ресурсы динамически подгружать?
Можно. С бубнами. Танцами… Вокруг костра… Дело то в том, что ресурс — это же отдельная ддлина, вот ее то и надо скомпилировать. В общем то это старый метод из WinForms, но встроенной поддержки в впф нет. На мой взгляд пробелма заключается в том, что в модели WPF не каждый элемент формы должен иметь имя, а только тот, к которому вы обращаетесь из кода, а это уже сильно затрудняет связывание элемента с конкретной строкой из ресурса.
Поэтому метод с расширениями и был выбран.
Ух как жить то страшно, оказывается О.о. Блин а интересно, сделать по аналогии с тем, как это сделали Qtшники возможно? Просто более удобного варианта я еще не встречал. В конечном итоге строчки, нуждающиеся в интернационализации оборачиваются в функцию tr(""); для C++ классов и qsTr(""); для javascript функций и QML документов. А встроенная в Qt утилита просто парсит исходники, находит все включения tr(""); translate("",""); QT_TRANSLATE_NOOP("",""); и тд… после чего генерит специальный файл, на основе которого делается файл переводов. И более того, если это графическая форма, то в программе — переводчике можно увидеть её предпросмотр.
Вот разве в WPF невозможно нечто похожее сделать?
Ну я привык оперировать понятиями, что с компьютерами нет ничего не возможного.
Со стороны работы со словарями — мы так и сделали, есть аддон к студии, который парсит код формы и делает нужные замены в нужных местах, создает файл переводов.
А вот что касается именно ран-тайма — то я не знаю как предложенный вами вариант работает в Qt, так что не могу ничего сказать.
Вот это одна из фич Qt, за которое я её люблю (=
Так, а как на счёт runtime? В wpf можно с помощью markupextentions сделать именно решение, которое бы «на лету» обновляло бы весь интерфейс при смене культуры.
Если Вы имеете ввиду satellite assembly, то они есть, но функции использования ресурсов в markup не предоставляется стандартными средствами dotNet. Можно делать wrapper над ресурсами, а можно это сделать предложенным выше подходом.
ИМХО тут следует упомянуть про одно из самых полезных применений markup extensions, а именно реализации DI/IoC для WPF-приложений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории