MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
Это сугубо индусская технология. Я пытался начать на WPF серьезный проект, с динамически генерящимися элементами UI и т.п. — это такое чортово вуду, что проще туда не лезть. Как альтернатива WindowsForms, ради мифического разделения работы по проектированию UI и кода на дизайнера и программиста — это очень мутная постановка вопроса.
Здравствуйте, belnetmon, Вы писали:
B>Это сугубо индусская технология. Я пытался начать на WPF серьезный проект, с динамически генерящимися элементами UI и т.п. — это такое чортово вуду, что проще туда не лезть. Как альтернатива WindowsForms, ради мифического разделения работы по проектированию UI и кода на дизайнера и программиста — это очень мутная постановка вопроса.
У меня лично сложилось совершенно противоположное впечатление. Как раз-таки серьезные проеты на нем и следует начинать. Да, бывает сложновато. И приступать что-то писать на WPF имхо, не стоит, не прочитав прежде толстенькую книгу про него, например хотя-бы http://www.ozon.ru/context/detail/id/3748933/.
Однако, после того как пощупаешь это дело, WinForms воспринимается уже просто технологией каменного века, и как раз-таки предназначенной для индусов или для создания макетов (вот для этого WinForms определенно рулит).
На WPF можно быстро и элегантно сделать такие хитрые вещи, которые на WinForms заняли бы в разы больше времени, и все равно были бы сделаны криво. Думаю, к WinForms возврата уже нет.
Что касается разделения работ по кодированию и дизайну — то это вовсе не главная фишка,а одна из многих (просто так уж сложилось, что объяснять отличие WPF начинают обычно с нее, и может сложиться ошибочное впечатление, что ради этого в основном все и замутили) и даже если бы ее вовсе не было, то это не умалило бы ценности WPF.
Здравствуйте, belnetmon, Вы писали:
B>Это сугубо индусская технология.
Означает ли это, что "неосилившие" — хуже индусов?
B>Я пытался начать на WPF серьезный проект, с динамически генерящимися элементами UI и т.п. — ...
... и оказалось, что это — не WinForms, ну надо же...
B>Как альтернатива WindowsForms, ради мифического разделения работы по проектированию UI и кода на дизайнера и программиста — это очень мутная постановка вопроса.
Эта альтернатива в сотни раз гибче Windows Forms. Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует. Только чур так, чтобы я еще мог этот ComboBox спокойно конфигурировать. Причем заметь, я бы хотел иметь возможность показывать ComboBox в разных элементах дерева одновременно.
WPF уступает Windows Forms, пожалуй, только по части сложных графических сцен, назовем их так. Это когда нужна ювелирная работа по отрисовке, штуки вроде SetPixel, да InvalidateRect. Но такой UI во многом редкость, да и это уже ближе к игровой графике, нежели прикладного пользовательского интерфейса. Что же касается, большинства задач обычных приложений, то WinForms сливает WPF подчистую. Но нужно потратить время, чтобы изучить технологию.
Здравствуйте, MozgC, Вы писали:
MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
У меня в одном проекте используется. Многие красивые и удобные вещи сделать на 2 порядка проще, чем в винформс, работает быстро, да и архитектура как-то посовременней выглядит, винформсы совсем динозавр страшный.
Недостаток — местами сильно переусложнено.
ИМХО — уже живет, жить будет и отъест около половины всего окошечного под .net. Главным образом там, где интерфейс сложный. Кстати VS2010 его уже юзает
Здравствуйте, sunshine, Вы писали:
>приступать что-то писать на WPF имхо, не стоит, не прочитав прежде толстенькую книгу про него
Именно так и было сделано, предваряло серьезное изучение и весьма глубокое копание.
S>Однако, после того как пощупаешь это дело, WinForms воспринимается уже просто технологией каменного века
Это в случае, если вам нужно от UI что-то типа "плетется курсор мыши — а под ним автоматом мигают кнопки, красиво". А если требования к UI бизнес, то мне это все не важно. Мне важно, что там нет нормального датагрида, например. Можно захостить винформовский, но это же уродство. Вот что является ключевым. Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. Просто такое использование в этой технологии изначально не предполагалось.
S>На WPF можно быстро и элегантно сделать такие хитрые вещи, которые на WinForms заняли бы в разы больше времени
Безусловно. Огромное количество прекрасных автоматических механизмов.
Скажу по собственным ощущениям. С WPF работаю уже три года, очень приятно, что технология не ставит ограничений.
Другой вопрос, что требуется кардинальная перестройка мышления и подхода к разработке UI. А на это, как выясняется,
способны далеко не все. Будущее у WPF есть, причем, с моей точки зрения, достаточно радужное, ибо в 4-й версии поправили
косяки со шрифтами, которые немало доставляли в свое время.
З.Ы. Тут на форуме периодически пробегают вопросы о том, как подменить элементы в готовом шаблоне и т.д. С моей точки зрения,
подобные извраты — следствие неудачной архитектуры приложения. Сам таким страдал года 2,5 назад. Потом стал писать по-другому
и надобность в подобных извратах отпала.
Здравствуйте, MxMsk, Вы писали:
MM>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Здравствуйте, belnetmon, Вы писали:
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
У меня в решении этой задачи вообще нет кода. А у тебя?
Здравствуйте, belnetmon, Вы писали:
B>Здравствуйте, sunshine, Вы писали:
S>>Однако, после того как пощупаешь это дело, WinForms воспринимается уже просто технологией каменного века
B>Это в случае, если вам нужно от UI что-то типа "плетется курсор мыши — а под ним автоматом мигают кнопки, красиво". А если требования к UI бизнес, то мне это все не важно. Мне важно, что там нет нормального датагрида, например. Можно захостить винформовский, но это же уродство. Вот что является ключевым. http://msdn.microsoft.com/en-us/library/system.windows.controls.datagrid(v=VS.100).aspx http://wpf.codeplex.com/releases/view/40535 для 3.5
B>Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами.
Что значит "строю вручную"?
B>Просто такое использование в этой технологии изначально не предполагалось.
Тогда делай как предполагалось, возможностей уйма.
Здравствуйте, belnetmon, Вы писали:
B>А у меня фреймворк, кодогенерация и весь UI под данного клиента и его специфику должен строиться динамически только из кода.
У тебя Windows Forms, и в этом твоя проблема. Тот пример, что я привел ранее, из кода тоже просто делается. Твое нытье про меню не впечатляет, потому что у меня тоже есть часть проги, в которой меню генерится из кода.
У меня 2008 студия, WPF тулкит и грид оттуда — ужасен
B>>Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. G>Что значит "строю вручную"?
Динамическая генерация UI из разных критериев. То есть меню и наполнение живут в метаданных, откуда загружаются и так строится UI.
G>Тогда делай как предполагалось, возможностей уйма.
Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него.
Чем ужасен? Он уж точно лучше стандартного винформовского.
Грид в SL и .NET 4 такой же.
B>>>Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. G>>Что значит "строю вручную"?
B>Динамическая генерация UI из разных критериев. То есть меню и наполнение живут в метаданных, откуда загружаются и так строится UI.
ItemsSource и Binding — будет счастье. Мало того что это очень простой способ (в разы проще, чем создавать Visual_ы руками), там еще и "концептуально правильный".
G>>Тогда делай как предполагалось, возможностей уйма. B>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него.
Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
Здравствуйте, belnetmon, Вы писали:
B>Это сугубо индусская технология. Я пытался начать на WPF серьезный проект, с динамически генерящимися элементами UI и т.п. — это такое чортово вуду, что проще туда не лезть. Как альтернатива WindowsForms, ради мифического разделения работы по проектированию UI и кода на дизайнера и программиста — это очень мутная постановка вопроса.
Это как раз очень хорошая и современная технология, и я не о градиентиках и бликах, я о подходах, гибкости и скорости разработки.
Кстати я тоже делал автогенерацию гуи по метаданным...
Здравствуйте, Flem1234, Вы писали:
F>У меня в одном проекте используется. Многие красивые и удобные вещи сделать на 2 порядка проще, чем в винформс, работает быстро, да и архитектура как-то посовременней выглядит, винформсы совсем динозавр страшный.
По поводу скорости работы я с тобой не согласен.
В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
в wpf встроена анимация, стандартная анимация сливает перерисовке по таймеру?
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, Flem1234, Вы писали:
F>>У меня в одном проекте используется. Многие красивые и удобные вещи сделать на 2 порядка проще, чем в винформс, работает быстро, да и архитектура как-то посовременней выглядит, винформсы совсем динозавр страшный.
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
Здравствуйте, Codechanger, Вы писали:
RT>>По поводу скорости работы я с тобой не согласен. RT>>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
C>UseCase в студию.
Рисуем Grid а ля Excel
1. Куча столбцов/колонок
2. Границы ячеек могут быть различной толцишы и различного цвета
3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены
4. Куча теста в ячейках написанных различными шрифтами
Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается.
RT>1. Куча столбцов/колонок RT>2. Границы ячеек могут быть различной толцишы и различного цвета RT>3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены RT>4. Куча теста в ячейках написанных различными шрифтами RT>Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается.
И каким образом вы решали это на wpf? Надеюсь не рисовали на Canvas?
