Здравствуйте, 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 однозначно неудобно ?