Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

Таких нет. Это все развод.

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.
Ты, конечно, тролишь, но попробуем. Во-первых, WPF — это не только средство отрисовки графики на экране, из чего следует, что судить о целесообразности ее применения только по внешнему виду нельзя. Во-вторых, в WPF все рисуется сглаженно и с учетом масштабирования

Автор: MxMsk
Дата: 12.11.10

, с чем в WinAPI и GDI+ придется, мягко скажем, повозиться.

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.

Для начала, советую приложение "Руской громатека для тырнед-общенья" — корректирует падежи, времена, склонения, пунктуацию и т.п.
А из WPF можно взглянуть на наше, "но я вам его не дам — у вас докУментов нет!" (ц)
Кратко, система документооборота. На каждый документ — свой класс. Создавать для всех 50 доков интерфейс — это убитьсибяапстену (форма редактирования, список и селектор — ШЕСТЬ разных файлов). Подправлять каждый документ, потому что кто-то захотел пимпочку — убить себя между двумя стенами всмятку. Засим, решено было генерировать интерфейс автоматом (перл-скрипт). Вот все формочки (вместе с кодом) и сделаны на WPF. Тюнинг отдельных редакторов свойств осуществляется через спец-комменты (а можно было на атрибутах). Уже несчётное число раз добавлял "пимпочки", перегенерировал формы и вуаля — весь интерфейс обновлён, корректно ресайзится и т.п. Думаю, это одно из блестящих применений WPF. А учитывая "документооборотистость" практически любой системы на основе СУБД, получаем неслабый бенефит.

Здравствуйте, matumba, Вы писали:

m> Для начала, советую приложение "Руской громатека для тырнед-общенья" — корректирует падежи, времена, склонения, пунктуацию и т.п.

Большое спасибо за совет, но к сожалению, google не знает о такой программе. Подкинь пожалуйста линк, если тебя это не затруднит.

m> А из WPF можно взглянуть на наше, "но я вам его не дам — у вас докУментов нет!" (ц)

Ну хотя бы скриншот можно увидеть?

m> Кратко, система документооборота... Вот все формочки (вместе с кодом) и сделаны на WPF.

Т.е. те же самые формочки и их генерацию было принципиально невозможно сделать на обычных WinForms? Или WPF тут значительно сократил время разработки?

Сорри, если я похож на чела, который тролит (см сообщение от MxMsk), но я вполне серьезно хочу найти причины по которым миграция на WPF принесет не только траблы (слабое распространение нужного фреймворка, не все компы топовой модели т.п) но и какие то преимущества обычному пользователю.

Здравствуйте, MxMsk, Вы писали:

MM> Ты, конечно, тролишь, но попробуем. Во-первых, WPF — это не только средство отрисовки графики на экране, из чего следует, что судить о целесообразности ее применения только по внешнему виду нельзя. Во-вторых, в WPF все рисуется сглаженно и с учетом масштабирования

Автор: MxMsk
Дата: 12.11.10

, с чем в WinAPI и GDI+ придется, мягко скажем, повозиться.

Я абсолютно не тролю. У меня есть приложение написанное на GDI+ и довольно широко используемое. В планах о дальнейшем развитии встал вопрос о "переезде" GUI на на WPF. Прежде чем на переделку будет брошено несколько человек стоит элементарный вопрос о целесообразности.
Все эти вопросы масштабирования и альязинга мне известны, но настолько ли это все важно, что бы пересаживаться на WPF...

Здравствуйте, HotDog, Вы писали:

HD>Я абсолютно не тролю.
Тогда не надо писать про моду.

HD>У меня есть приложение написанное на GDI+ и довольно широко используемое. В планах о дальнейшем развитии встал вопрос о "переезде" GUI на на WPF. Прежде чем на переделку будет брошено несколько человек стоит элементарный вопрос о целесообразности.
HD>Все эти вопросы масштабирования и альязинга мне известны, но настолько ли это все важно, что бы пересаживаться на WPF...
Могу подкинуть следующие ссылки: WPF vs WinForms

Автор: x64
Дата: 23.03.10

. Конкретнее здесь

Автор: mrTwister
Дата: 23.03.10

и недалеко оттуда

Автор: MxKazan
Дата: 24.03.10

.

Здравствуйте, HotDog, Вы писали:

HD>Здравствуйте, MxMsk, Вы писали:

MM>> Ты, конечно, тролишь, но попробуем. Во-первых, WPF — это не только средство отрисовки графики на экране, из чего следует, что судить о целесообразности ее применения только по внешнему виду нельзя. Во-вторых, в WPF все рисуется сглаженно и с учетом масштабирования

Автор: MxMsk
Дата: 12.11.10

, с чем в WinAPI и GDI+ придется, мягко скажем, повозиться.

HD>Я абсолютно не тролю. У меня есть приложение написанное на GDI+ и довольно широко используемое. В планах о дальнейшем развитии встал вопрос о "переезде" GUI на на WPF. Прежде чем на переделку будет брошено несколько человек стоит элементарный вопрос о целесообразности.
HD>Все эти вопросы масштабирования и альязинга мне известны, но настолько ли это все важно, что бы пересаживаться на WPF...

вопросы масштабирования и алиасинга — это не единственные бонусы wpf.

Вам надо просто детально возможности технологии, включая такие неочевидные вещи, как упрощение автотестирования кода и уменьшение связности business и presentation слоев приложения. Потом надо просто взять листик, с одной стороны написать полезные именно вам возможности wpf с цифрами заработка или экономии связанной с их внедрением, а с другой стороны список работ, которые необходимо выполнить, чтоб внедрить соответствующие возможности с их стоимостью. Полученные цифры в столбиках сложить, из суммы левого столбика вычесть сумму правого, если результат больше нуля, берите и внедряйте.

Здравствуйте, HotDog, Вы писали:

HD> но и какие то преимущества обычному пользователю.

После перехода на wpf, кол-во багов, попадающих в релиз, у нас на фирме сократилось примерно в 3 раза. В приложении очень сложный UI с сотнями юзкейсов, абсолютно все оттестить в приемлемые сроки с приемлемым бюджетом до использования бенефитов wpf было нереально. В этой связи переход на wpf пользователям очень понравился

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

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

Здравствуйте, Visor2004, Вы писали:

V> имхо нет способа лучше проверить технологию, так это написать с ее помощью прототип того, что требуется. Просто попробуйте я думаю оч. быстро сами увидите подходит оно вам или нет, на форуме все равно никто не знает вашей специфики.

Я ж не спрашивал о специфике или трудностях тестирования или реализации. Я просто попросил поделится ссылками на WPF приложения, которые без этого самого WPF выглядели бы "чахло". Меня интереcует именно GUI, хардварная поддержка, шейдеры и все то, что стоит именно за термином Presentation Foundation.

У меня складывается впечатление, что WPF по настоящему еще не выстрелил, хотя уже прошло 4 года со дня релиза (.NET 3.0). И отсутствие серьезных приложений использующих всю "мощь" Presentation Foundation заставляет задуматься над тем, а нужно ли оно.
Я в курсе о VS 2010 и AutoCAD 2011. Чисто визуально эти приложения ничего не выиграли от применения WPF.

Здравствуйте, HotDog, Вы писали:

HD>Здравствуйте, Visor2004, Вы писали:

V>> имхо нет способа лучше проверить технологию, так это написать с ее помощью прототип того, что требуется. Просто попробуйте я думаю оч. быстро сами увидите подходит оно вам или нет, на форуме все равно никто не знает вашей специфики.

HD>Я ж не спрашивал о специфике или трудностях тестирования или реализации. Я просто попросил поделится ссылками на WPF приложения, которые без этого самого WPF выглядели бы "чахло". Меня интереcует именно GUI, хардварная поддержка, шейдеры и все то, что стоит именно за термином Presentation Foundation.

HD>У меня складывается впечатление, что WPF по настоящему еще не выстрелил, хотя уже прошло 4 года со дня релиза (.NET 3.0). И отсутствие серьезных приложений использующих всю "мощь" Presentation Foundation заставляет задуматься над тем, а нужно ли оно.
HD>Я в курсе о VS 2010 и AutoCAD 2011. Чисто визуально эти приложения ничего не выиграли от применения WPF.

тут каталог из 50ти штук

http://www.noupe.com/showcases/50-interactive-silverlight-applications.html

Здравствуйте, HotDog, Вы писали:

HD>Здравствуйте, Visor2004, Вы писали:

V>> имхо нет способа лучше проверить технологию, так это написать с ее помощью прототип того, что требуется. Просто попробуйте я думаю оч. быстро сами увидите подходит оно вам или нет, на форуме все равно никто не знает вашей специфики.

HD>Я ж не спрашивал о специфике или трудностях тестирования или реализации. Я просто попросил поделится ссылками на WPF приложения, которые без этого самого WPF выглядели бы "чахло". Меня интереcует именно GUI, хардварная поддержка, шейдеры и все то, что стоит именно за термином Presentation Foundation.

HD>У меня складывается впечатление, что WPF по настоящему еще не выстрелил, хотя уже прошло 4 года со дня релиза (.NET 3.0). И отсутствие серьезных приложений использующих всю "мощь" Presentation Foundation заставляет задуматься над тем, а нужно ли оно.
HD>Я в курсе о VS 2010 и AutoCAD 2011. Чисто визуально эти приложения ничего не выиграли от применения WPF.

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

Здравствуйте, HotDog, Вы писали:

HD>Я ж не спрашивал о специфике или трудностях тестирования или реализации. Я просто попросил поделится ссылками на WPF приложения, которые без этого самого WPF выглядели бы "чахло". Меня интереcует именно GUI, хардварная поддержка, шейдеры и все то, что стоит именно за термином Presentation Foundation.
Ок, а для чего люди переходили на MFC или Windows Forms, когда в конечном счете визуально всё достигается при помощи WinAPI?

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

Вставлю свои две копейки.

Конечно все можно написать на GDI, вопрос только в цене.

Приложения посмотрите в примерах к Expression Blend. Все очень красочно. Кодируется достаточно просто, во многих случаях 100% декларативно (100% xaml, без шарпа).

Главные плюсы wpf'а
1) Легкость (относительная) кодирования сложной графики и нетипового гуя.
2) высокая декларативная мощность. Дизайн гуя хорошо отделяется от логики.
3) поддержка анимации и 3d-графики на уровне фреймворка
4) возможность прицепить свое оформление к чужому контролу "сбоку", т.е. не влезая в сам контрол
5) во многих случаях возможность переезда в silverlight малой кровью. Т.е. ваше приложение будет открываться в бразурере.

Однако суровая реальность в том, что технология пока достаточно сырая.
1) Ублюдочное сглаживание шрифтов толком не вылечили и в .Net 4.0
2) Плохо работает интеграция с нативными окнами. Причем как WPF на нативном окне, так и нативное окно в WPF'е. Со вторым вообще очень большие проблемы.
3) Огромное, нереально большое количество косяков для которых приходится искать обходные пути.
4) Большие проблемы с ипользованием WPF'а на веб-сервере для генерации картинок для веб-приложения. Эта задача на самом деле достаточно востребованная.

Из опыта интеграции WPF в наше тяжеловесное гетерогенное приложение вывод следующий: в целом пока проблем больше чем профита. Но технология перспективная, мелкомягкие должны со временем довести до ума.

Здравствуйте, Andreo_K, Вы писали:


A_K>Приложения посмотрите в примерах к Expression Blend.

И на сам Expression стоит посмотреть — он весь сделан на WPF

Здравствуйте, Andreo_K, Вы писали:

A_K>Однако суровая реальность в том, что технология пока достаточно сырая.
A_K>1) Ублюдочное сглаживание шрифтов толком не вылечили и в .Net 4.0
Да ладно. Сейчас все рисуется отлично. Возможно некоторое привыкание еще требуется, но уж точно ничего "ублюдочного".

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Andreo_K, Вы писали:

A_K>>Однако суровая реальность в том, что технология пока достаточно сырая.
A_K>>1) Ублюдочное сглаживание шрифтов толком не вылечили и в .Net 4.0
MM>Да ладно. Сейчас все рисуется отлично. Возможно некоторое привыкание еще требуется, но уж точно ничего "ублюдочного".

При масштабировании все плохо в режиме TextFormattingMode=Display. А в режиме Ideal плохо без масштабирования.

Раньше конечно было хуже, с этим не поспоришь

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.
Вот здесь не большой каталог простеньких приложений, которые используют никому не известные компании
http://10rem.net/blog/2010/02/10/the-book-of-wpf

Здравствуйте, 413X, Вы писали:

X>Здравствуйте, HotDog, Вы писали:
X>которые используют никому не известные компании

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

Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, 413X, Вы писали:

X>>Здравствуйте, HotDog, Вы писали:
X>>которые используют никому не известные компании

V>Это вы по горячности, если имя не на слуху, не значит, что о нем не слышал вообще никто. То что небольшие кампании выбирают wpf, косвенно говорит нам, что с этого есть какой-то экономический профит.
это была шутка , там в каталоге компании калибра HP, AMD, Intel и т.д.

Здравствуйте, 413X, Вы писали:

X>Здравствуйте, Visor2004, Вы писали:

V>>Здравствуйте, 413X, Вы писали:

X>>>Здравствуйте, HotDog, Вы писали:
X>>>которые используют никому не известные компании

V>>Это вы по горячности, если имя не на слуху, не значит, что о нем не слышал вообще никто. То что небольшие кампании выбирают wpf, косвенно говорит нам, что с этого есть какой-то экономический профит.
X>это была шутка , там в каталоге компании калибра HP, AMD, Intel и т.д.
кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .

Здравствуйте, 413X, Вы писали:

X>Здравствуйте, 413X, Вы писали:

X>>Здравствуйте, Visor2004, Вы писали:

V>>>Здравствуйте, 413X, Вы писали:

X>>>>Здравствуйте, HotDog, Вы писали:
X>>>>которые используют никому не известные компании

V>>>Это вы по горячности, если имя не на слуху, не значит, что о нем не слышал вообще никто. То что небольшие кампании выбирают wpf, косвенно говорит нам, что с этого есть какой-то экономический профит.
X>>это была шутка , там в каталоге компании калибра HP, AMD, Intel и т.д.
X>кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .

Двойной щелчок на заголовке окна не работает, окошко я настройками нельзя тягать за заголовок, при разворачивании окна на весь экран панель задач в режиме auto-hide перестает показываться. Возьмите Microsoft.Win32.Shell.dll для работы с Window Chrome.
При открытии нового окна оно показывается в левом верхнем углу экрана, по центру имхо лучше было бы.
Понравился концепт с кнопкой разворота на весь экран и 3D эффекты смотрятся хорошо и к месту. Хотя и притормаживают, хотя дело имхо в медленной анимации duration надо имхо меньше сделать повороту кубика в главном окне.

Для начала, очень даже не плохо

Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, 413X, Вы писали:

X>>Здравствуйте, 413X, Вы писали:

X>>>Здравствуйте, Visor2004, Вы писали:

V>>>>Здравствуйте, 413X, Вы писали:

X>>>>>Здравствуйте, HotDog, Вы писали:
X>>>>>которые используют никому не известные компании

V>>>>Это вы по горячности, если имя не на слуху, не значит, что о нем не слышал вообще никто. То что небольшие кампании выбирают wpf, косвенно говорит нам, что с этого есть какой-то экономический профит.
X>>>это была шутка , там в каталоге компании калибра HP, AMD, Intel и т.д.
X>>кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .

V>Двойной щелчок на заголовке окна не работает, окошко я настройками нельзя тягать за заголовок, при разворачивании окна на весь экран панель задач в режиме auto-hide перестает показываться. Возьмите Microsoft.Win32.Shell.dll для работы с Window Chrome.
V>При открытии нового окна оно показывается в левом верхнем углу экрана, по центру имхо лучше было бы.
V>Понравился концепт с кнопкой разворота на весь экран и 3D эффекты смотрятся хорошо и к месту. Хотя и притормаживают, хотя дело имхо в медленной анимации duration надо имхо меньше сделать повороту кубика в главном окне.

V>Для начала, очень даже не плохо
спасибо большое, но это не порка
просто небольшая защита технологии WPF, которая мне очень импонирует

Здравствуйте, 413X, Вы писали:

X>спасибо большое, но это не порка
X>просто небольшая защита технологии WPF, которая мне очень импонирует
Сорь, не сдержалсо, хотел внести посильную помощь

Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, 413X, Вы писали:

X>>спасибо большое, но это не порка
X>>просто небольшая защита технологии WPF, которая мне очень импонирует
V>Сорь, не сдержалсо, хотел внести посильную помощь
спасибо еще раз, пожелания учтены

Здравствуйте, HotDog, Вы писали:

HD>Т.е. те же самые формочки и их генерацию было принципиально невозможно сделать на обычных WinForms? Или WPF тут значительно сократил время разработки?

Охотно расскажу. Дело в том, что ХАМЛ как ХТМЛ — декларативная штука, где очень просто организовать ирерархию контролов.
ВыньФормс:
1. Создать контрол
2. Инициализировать его свойства, включая расположение. В принципе, это уже засада — откуда мне знать, на каком смещении от верха оно расположено?? Далее...
3. Создать контейнер (если нужно)
4. Добавить контрол в контейнер, который в свою очередь тоже нужно куда-то добавить.
(и всё это делается в строгом порядке)

В ХАМЛе:
1. Готовим общий шаблон (прямо в дизайнере).
2. Маркируем места для контролов
3. Шлёпаем вместо маркеров произвольное количество контролов (текстбоксы, колонки, слайдеры и т.п.) с заранее известными ХАМЛ-атрибутами — достаточно простыми для нас и достаточно информативными для layout manager'а.

Всё.

Т.е. если сильно поднапрячься, можно и ВыньФормс как-то одолеть, написав дополнительный древовидный энжын, который как-то более-менее расставит контролы автоматом. Но в ВПФ это делается лёгким движением руки, экономя время разработки как таковое (т.к. разметка ХАМЛ намного проще), ХАМЛ достаточно просто модифицируется (под новые требования разметки) и ХАМЛ легко продуцировать — не нужно соблюдать порядок создания. Текущая реализация моего конвертера была уже улучшена уйму раз, я лишь подправляю шаблоны и ввожу дополнительные функции. Просто не представляю, сколько фигни пришлось бы писать для ВыньФормс...
Но все эти преимущества, повторю, для автоматического создания интерфейса. Если все ваши формы "ручной работы", то нужно уже сравнивать по другим критериям — лёгкости стилизации или простоте заточки под требования, например. Вот у меня возникла "задача" — сделать надпись на кнопке двустрочной. Если кнопка это не поддерживает, придётся переопределять Draw, вычислять расположение, рисовать... На ВПФ достаточно сделать так:

<Button>
   <TextBlock TextAlignment="Center">Edit<LineBreak/>Objective</TextBlock>
</Button>

Или сделать листбокс со скроллбарами слева и отображением элементов в виде таблички — пишется простыня шаблона и оно работает без перекомпиляции — на стандартных контролах. (хотя честно скажу, писать шаблоны — это нехилая работа)

Вообще, про ВПФ нужно дофига читать — они там наворотили много (даже чересчур ), поэтому решать "WPF or not WPF" можно только попробовав всё руками и испытав на реальном проекте.

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

Очень интересно вы рассказываете. Расскажите еще и поподробней. Из чего вы генерируете? В какой момент(компиляция или время исполнения)?

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

Присоединяюсь к вопросу. Как я понял из обсуждения — WPF показал себя очень удобным при автогенерации форм.

Вопрос — как вам показался WPF для создания форм жестского контроля ? То есть — тех, где местоположение контролов, действия на них и вообще — дизайн и идея формы жестко программируется при разработке пользовательского интерфейса. С Winforms понятно — мышевозилово, события и частая каша бизнес-слоя с интерфейсом.

Здравствуйте, Аноним, Вы писали:

M>>Текущая реализация моего конвертера была уже улучшена уйму раз, я лишь подправляю шаблоны и ввожу дополнительные функции.
А>Очень интересно вы рассказываете. Расскажите еще и поподробней. Из чего вы генерируете? В какой момент(компиляция или время исполнения)?

Решение проще "калашникова": перл скрипт принимает на вход обычный .cs файл бизнес-сущностей, там ищет классы и выделяет в них поля. Класс выглядит примерно так:

    public class DeedOfAssignment : Document
    {
        //$ tab=General
        public string Keywords { get; set; }
        public string Description { get; set; }//$ memo
        public string LegacyRef { get; set; }//$ label=Legacy_ref
        public string Parties { get; set; }//$ multi=Company|Person
        public string Scope { get; set; }//$ memo
        //$ tab=Other
        public DateTime? AgreementDate { get; set; }//$ label=Agreement_date
        public DateTime? ExpiryDate { get; set; }//$ label=Expiry_date
        public int? StatusID { get; set; }//$ choice=Status
        public int? CurrencyID { get; set; }//$ choice=Currency
        public double? BudgetedCost { get; set; }//$ label=Budgeted_cost
        public double? ActualCost { get; set; }//$ label=Actual_cost
    }

На выходе генерится форма DeedOfAssignment.xaml + DeedOfAssignment.xaml.cs, которые копируются в папку программы (в проекте они уже подключены).
Спецкомменты //$ — это указания конвертеру на тюнинг полей: choice — сгенерить комбобокс (данные автоматом подключаются из указанной таблицы), multi — это listbox выбора нескольких сущностей.
Если у класса есть наследник (здесь Document), к нему дописываются поля родителя. tab=*** — сгенерить новую закладку и последущие элементы класть уже туда.
Понятно, что Ъ-шарповоды предпочтут атрибуты и обрабатывать всё тем же C#, но я сделал как мне было проще.
Если форма сложная, я всё равно генерю автоматом форму, но потом допиливаю в студии — экономится куча времени.
"Шаблоны" засунуты прямо в скрипт методом heredoc. Причём некоторые элементы кода неизвестны до самого конца — они накапливаются в переменных и потом вместе с шаблоном выводятся.

Здравствуйте, Nikolay_P_I, Вы писали:

HD>>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

N_P>Присоединяюсь к вопросу. Как я понял из обсуждения — WPF показал себя очень удобным при автогенерации форм.

N_P>Вопрос — как вам показался WPF для создания форм жестского контроля ? То есть — тех, где местоположение контролов, действия на них и вообще — дизайн и идея формы жестко программируется при разработке пользовательского интерфейса. С Winforms понятно — мышевозилово, события и частая каша бизнес-слоя с интерфейсом.

Открываешь редактор и пишешь разметку. автогенерация форм — это идиотический пережиток, костыль, который в wpf не нужен ибо есть DataTemplates.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Вопрос — как вам показался WPF для создания форм жестского контроля ? То есть — тех, где местоположение контролов, действия на них и вообще — дизайн и идея формы жестко программируется при разработке пользовательского интерфейса. С Winforms понятно — мышевозилово, события и частая каша бизнес-слоя с интерфейсом.
У нас вообще нет автогенерации. В WinForms — "мышевозилово", в WPF — редактирования текста. На порядок удобнее.

Здравствуйте, MxMsk, Вы писали:

N_P>>Вопрос — как вам показался WPF для создания форм жестского контроля ? То есть — тех, где местоположение контролов, действия на них и вообще — дизайн и идея формы жестко программируется при разработке пользовательского интерфейса. С Winforms понятно — мышевозилово, события и частая каша бизнес-слоя с интерфейсом.
MM>У нас вообще нет автогенерации. В WinForms — "мышевозилово", в WPF — редактирования текста. На порядок удобнее.

Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Здравствуйте, MxMsk, Вы писали:

N_P>>>Вопрос — как вам показался WPF для создания форм жестского контроля ? То есть — тех, где местоположение контролов, действия на них и вообще — дизайн и идея формы жестко программируется при разработке пользовательского интерфейса. С Winforms понятно — мышевозилово, события и частая каша бизнес-слоя с интерфейсом.
MM>>У нас вообще нет автогенерации. В WinForms — "мышевозилово", в WPF — редактирования текста. На порядок удобнее.

N_P>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.
Почитатйте вот этоItemsControl
потом это по тегам ItemsControl
+ внимательно просмотрите всю иерархию разных ItemsControl, которые предлагает wpf. ListView и DataGrid — это тоже ItemsControl.
Советую не пожалеть времени и ОЧЕНЬ внимательно ознакомится с понятием DataTemplate

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.
Хорошо. Нам требуется представлять определенные данные по транспорту на графике. По вертикальной оси располагаются населенные пункты, причем они сгруппированы так, что получается древовидная структура. Нечто вроде "Страна -> Область -> Населенный пункт". Пользователь должен иметь возможность сворачивать и разворачивать ветки дерева, для каждого населенного пункта требуется предоставлять рядом с названием различную доп.информацию. Что мы сделали. Накатали модель с древовидным списком бизнес-объектов. Взяли обычный TreeView, переопределили шаблоны данных и всё. В результате получили визуальное дерево населенных пунктов, которое работает аналогично стандартному TreeView, но при этом в части его узлов легко встроены ComboBox-ы для выбора дополнительной информации. Содержимое дерева и действия пользователя с ним автоматически синхронизируются с моделью через привязку данных (то бишь мы отделили логику от представления). Теперь представим сколько нужно сделать в Windows Forms хотя-бы для полноценного встраивания ComboBox в TreeNode.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.
Добавлю к этому

Автор: MxMsk
Дата: 27.11.10

еще такую фичу, как присоединяемые свойства. Понадобилось ловить клик мышки на узлах дерева. Как сделать по старинке? Добавить во View событие и подписываться на него в контроллере. В самом View придется подписываться на событие дерева и транслировать вызов в событие интерфейса View. Как мы сделали это в WPF? Взяли Caliburn, у которого есть Action-ы. Эта такие штуковины, которые позволяют вызывать методы модели в ответ на возникновение событий в контролах. Присоединили к TreeView список Action-ов, в том числе для события Click. Добавили в модель метод OnTreeNodeClick и вуаяля. Никакой заботы с подпиской/отпиской, никакой возни с делегированием событий и наворачиванием интерфейсов представления и контроллера на каждый чих.

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, HotDog, Вы писали:

HD>>Я ж не спрашивал о специфике или трудностях тестирования или реализации. Я просто попросил поделится ссылками на WPF приложения, которые без этого самого WPF выглядели бы "чахло". Меня интереcует именно GUI, хардварная поддержка, шейдеры и все то, что стоит именно за термином Presentation Foundation.
MM>Ок, а для чего люди переходили на MFC или Windows Forms, когда в конечном счете визуально всё достигается при помощи WinAPI?

На Winforms быстрее (читай дешевле) писать софт, чем на mfc. Но с WPF ситуация ровно противоположная: на нем все делать получается МЕДЛЕННЕЕ, а все их крутые концепции, ради которых получается оверхед, в подавляющем большинстве случаев нафиг никому не нужны.

HL>На Winforms быстрее (читай дешевле) писать софт, чем на mfc. Но с WPF ситуация ровно противоположная: на нем все делать получается МЕДЛЕННЕЕ, а все их крутые концепции, ради которых получается оверхед, в подавляющем большинстве случаев нафиг никому не нужны.
Почему это медленнее? Наоборот. У меня есть параллельные проекты под WinForms и WPF/Silverlight с одинаковой функциональностью. Скорость, с которой у Вас что-то получается, зависит только от Вашего умения их готовить. Большинство вещей в WPF как раз удобней и быстрей делается.
Хотя может быть вы в WinForms делаете что-то сильно специфическое именно для WinForms? Тогда скажите что именно, навскидку мне в голову ничего не приходит

Здравствуйте, HotDog, Вы писали:

HD>Посоветуйте плиз приложений на которые стоит взглянуть и которые оправдывают использование WPF.
HD>Пошарил по инету и навскидку только PhotoSuru выглядит довольно гармонично.
HD>Все остальной что я видел — да, использует WPF, но как то притянуто за уши — чистая дань моде
HD>и тот же WinAPI, GDI+ отрисовали бы интерфейс не хуже.

WinAPI, GDI+ и Direct2D не сравнятся с WPF по скорости разработки. Real artists ship, как говорил Стив Джобс. Это самое главное достоинство WPF. Для разработчиков. А достоинств для конечных пользователей придётся по-прежнему добиваться своими силами.

N_P>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.

Спасибо всем ответившим!

Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
Игрушки, hi-perf рендер (конечно, можно захостить 3d-surface, но если 99% вашего приложения — именно сам рендер, от WPF толку не будет), критичные к ресурсам приложения и софт под древние винды/mono, софт, использующий готовый конструктор под win-forms.

Вроде всё. Даже splash на wpf-окошке оказался не сильно тормознутее WinForms-оригинала. На достаточно слабых машинах.

Пару лет назад я бы добавил к списку софт, предназначенный для работы с текстом, но щас ситуация явно улучшилась.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно?
Надо понимать, что WPF — это не API для рисования, а набор решений для построения пользовательского интерфейса. Поэтому, как правильно написал Sinix, если требуется очень много и интенсивно рендерить динамические сцены, WPF сольет по производительности почти всему. Вот статика там хорошо работает: построил сцену и живет она себе, ожидая действий пользователя. А для всяких game-like штуковин лучше Direct2D и т.п.

X>кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .

За 1 мес. — это full-time или по вечерам? А перевертывание страниц в 3D сами делали?

Здравствуйте, Kerbadun, Вы писали:

X>>кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .

K>За 1 мес. — это full-time или по вечерам? А перевертывание страниц в 3D сами делали?
Ну вообще тяжело посчитать затраченное время, делал в свободное от работы, причем очень долго возился с графикой нежели с кодом, ибо рисовать вообще не умею.
страницы — алгоритм не мой.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.

N_P>Спасибо всем ответившим!

N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?

Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;

Здравствуйте, Visor2004, Вы писали:

N_P>>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?

V>Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;

А в чем проблемы с терминальными сессиями и что подразумевается под "серверными утилитами" ?

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Здравствуйте, Visor2004, Вы писали:

N_P>>>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?

V>>Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;

N_P>А в чем проблемы с терминальными сессиями и что подразумевается под "серверными утилитами" ?

сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.

Здравствуйте, Visor2004, Вы писали:

V>сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.

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

С теоретической — всё работает из коробки, начиная с 3.5sp1. Под RDP 7 всё вообще прекрасно. Советую посмотреть "History and background" и ниже.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Visor2004, Вы писали:

V>>сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.

S>С практической точки зрения: тут у людей проблемы с руками, не с WPF.

S>С теоретической — всё работает из коробки, начиная с 3.5sp1. Под RDP 7 всё вообще прекрасно. Советую посмотреть "History and background" и ниже.

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

Здравствуйте, Visor2004, Вы писали:

V>Ну я ведь не спорю с тем, что если поприседать, то можно добиться приемлемой работы и в терминале, я просто указываю на то, что есть трудности тут.

Во-первых, всего приседаний: — _не_ использовать анимации / тяжёлые градиенты с прозрачностью, если WinForms.SystemInformation.TerminalSession = true (по памяти. для wpf — не вспомню).

Во-вторых, с нативным софтом будут ровно те же проблемы.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?

Отвечу как троль из КСВ (можно всерьез не воспринимать).
Не рекомендуется использовать WPF в ответственных приложениях, где нужна качественная прорисовка без косяков. Например, не стоит использовать WPF в таких приложениях как Visual Studio 2010.
Ну в окне текстового редактора, конечно кривизну не видно.
Но откройте какую нибудь формочку из студии, например PerfomanceExplorer. Небольшая формочка с графиком, небольшой таблицей. Начинаешь скролить ее по горизонтали. И мало того что тормозит, но все части формы движутся отдельно, одни движутся другие застревают, потом догоняют.
На формочке где большая таблица, при скроллинге заголовок столбцов отделяется от таблицы и движется сам по себе.
В формочке диаграмм классов, если один класс развернуть, потом свернуть, то после этого зум начинает работать так. Картинка нарисованная по центру сначала прыгает в сторону, рисуется там, потом перепрыгивает в центр и снова перерисовывается.

Если кто-то скажет что просто у разработчиков студии руки кривые, просто не умеют правильно готовить WPF. То будет даже смешно.

Быстрая разработка — нашлопали XAML, биндингов и конвертеров, за 5% времени. А остальные 95% времени придумывать как косяки исправить, либо сказать "A .. и так сойдет"

Здравствуйте, Silver_s, Вы писали:

S_> Если кто-то скажет что просто у разработчиков студии руки кривые, просто не умеют правильно готовить WPF. То будет даже смешно.
Можешь не смеяться, но ты просто не стал тратить время на изучение технологии. Те же, кто ее изучил, знает узкие места и научился их обходить. Не в курсе, что там с Performance Explorer, но у нас прога, которая показывает график с более чем 500-ми объектами, каждый из которых рисуется не самой простой геометрией. Чтобы заставить это хорошо работать пришлось потратить время, но я не вижу в этом ничего страшного, потому что технология новая и оптимизировать приходилось, так сказать, эмпирическим путем. Теперь есть багаж знаний и он позволяет ибегать проблем. И не надо здесь рассказывать про Windows Forms, косяки которого вдоль и поперек изучены не одним поколением программистов, начиная с появления WinAPI.