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.
Здравствуйте, RadmirT, Вы писали:
Q>>Причём здесь создаются тяжеловесные Shape'ы, а можно рисовать более низкоуровневые freeze'анутые StreamGeometry, например. RT>Согласен. Роботает довольно быстро. Но.. RT>1. Все равно медленне чем WinForms
Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
Здравствуйте, RadmirT, Вы писали:
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
Это зависит от размера элемента. Постоянно перерисовывать кнопочку 100 x 100 — не проблема. Реальный слив вот где происходит. Допустим, что нам нужно рисовать на элементе какую-нибудь карту или, скажем, координатную сетку графика. Размеры такого элемента могут быть очень велики, например, 200000 x 1000. Понятно, что такой элемент не виден весь. Организация рендеринга в WPF такова, что у меня появляется выбор: либо нарисовывать весь элемент в OnRender, либо добавить полосы прокрутки и перерисовывать видимую часть элемента при изменении их положения. Так вот в первом случае, появляется слишком много графических примитивов. Еще бы! Там же 200 штук пикселов по горизонтали! И это тормозит. Второй вариант — перерисовка при прокрутке — тоже тормозит, если область видимости будет достаточно велика, например, 1680 x 1050. По опыту работы с Windows Forms, там такое организовать проще, потому что она более ориентирована именно на рисование, а не на компоновку пользовательского интерфейса. Справедливости ради стоит отметить, что такие задачи редки и просто потребуют чуть больше геморроя в коде. И потом, это все-таки не приоритетное направление WPF.
Здравствуйте, Qbit86, Вы писали:
Q>Насчёт в «GDI+ быстрее, чем в DirectX» у меня есть большие сомнения. Примеры ведь в этой ветке были только с моей стороны.
Я не утверждаю что "GDI+ быстрее, чем в DirectX" сли бы это было бы так, то DirectX никому не был бы нужен.
Я говорю что в конкретном случае, когда необходимо оперироват большим количеством примитивов,которые постоянно удаляются/добавляются, использования WinForms + GDI+ эффективнее чем WPF + DirectX
Здравствуйте, belnetmon, Вы писали:
B>А у меня фреймворк, кодогенерация и весь UI под данного клиента и его специфику должен строиться динамически только из кода.
У тебя Windows Forms, и в этом твоя проблема. Тот пример, что я привел ранее, из кода тоже просто делается. Твое нытье про меню не впечатляет, потому что у меня тоже есть часть проги, в которой меню генерится из кода.
Здравствуйте, MxMsk, Вы писали: MM>А что, все программы в мире только и делают, что используют "элемент управления который отображает таблицу а ля Excel"? Этим же WPF не ограничивается. К чему этот стеб про "няшки"? Я никоим образом не имел ввиду ни анимацию, ни aero, ни 3D. Главным образом WPF — это грамотный компоновщик и привязка данных. И потом, если не заметил, то я подтвердил
, что при большом количестве примитивов есть тормоза. Но эту проблему можно попробовать решить частичным рисованием: в области, большей чем видимая, но меньшей, чем огромный компонент.
Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Здравствуйте, MozgC, Вы писали:
MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
Технология отличается чрезвычайной гибкостью, но при этом весьма высоким порогом вхождения. Те у кого хватит способностей справиться с порогом вхождения будут её использовать безусловно. Справится ли с этим в целом индустрия — вопрос интересный. Скорее всего компании, занимающиеся UI компонентами, наклепают компонентов попроще и подоступнее в использовании и будет всем счастье.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, belnetmon, Вы писали:
B>Здравствуйте, MxMsk, Вы писали:
MM>>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Понятие "стандартных" и "нестандартных" элементов управления возникают, в основном, из-за технологии и инструментов, которые ты используешь. Да, для WinForms такое элемент "нестандартен". И ты именно так и думаешь.
Вот тебе и говорят, что WPF в этом смысле гибче. И то что в Формс "нестандартно" тут делается вообще без кодирования и становиться "стандартным".
Чем ужасен? Он уж точно лучше стандартного винформовского.
Грид в SL и .NET 4 такой же.
B>>>Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. G>>Что значит "строю вручную"?
B>Динамическая генерация UI из разных критериев. То есть меню и наполнение живут в метаданных, откуда загружаются и так строится UI.
ItemsSource и Binding — будет счастье. Мало того что это очень простой способ (в разы проще, чем создавать Visual_ы руками), там еще и "концептуально правильный".
G>>Тогда делай как предполагалось, возможностей уйма. B>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него.
Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
Здравствуйте, me2, Вы писали:
me2>Первое время все казалось сложным, но стоит только разобраться — не так и страшно.
А по-моему, всё ровно наоборот: сначала смотришь примитивные примеры — о, да это как два байта переслать! А как начинаешь разбираться — боже мой... чесание левого уха правой рукой, в которую загипсован чесальщик спины для левой ноги. Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски. Авторское "Drat and double drat!" достаточно хорошо выражает общую мысль. Нет, не читайте решение — сначала решите сами, а потом спросите себя — стоило ваше время того тривиального эффекта, что вы достигли?
me2>p.s. При большом желании можно так же все в коде писать.
Не "так же", WPF предполагает совершенно другую модель, под которую надо менять мозг и весь опыт. WinForms был намного проще и прямолинейнее в достижении целей.
Мне "гибкость и мощь" WPF напоминает радиоконструктор — если всё чётко по схеме и без выпендрёжей (т.е. кастомизации) — да, спаял и всё работает. Но стоит подумать о снижении помех или увеличении мощности, как понимаешь, что не одними микрофарадами жив конденсатор — СТОЛЬКО всего приходится учить, что полжизни нужно потратить. Чего ради? Ради маркетоидной "гибкости"? Мне не нужна полдюймовая дрель, мне нужна полдюймовая дыра без головной боли — ДРУГИХ забот навалом. Так что в моём видении WPF как-то почертыхается, но потом все всё равно придут к очевидному — затраты на обучение и секс с шаблонами по каждому чиху не окупают результата — либо WPF упростят до дельфийских DFM'ок, либо ещё какую трёхбуквенную хрень придумают.
Здравствуйте, Codechanger, Вы писали:
RT>>По поводу скорости работы я с тобой не согласен. RT>>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
C>UseCase в студию.
Рисуем Grid а ля Excel
1. Куча столбцов/колонок
2. Границы ячеек могут быть различной толцишы и различного цвета
3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены
4. Куча теста в ячейках написанных различными шрифтами
Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается.
Здравствуйте, Sinix, Вы писали:
S>Проблема не столько в архитектуре WPF....
Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
S>...или копипастом всего шаблона с прилегающими стилями и правкой всего с 0.
Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей либо они не решали ничего, сложнее кастомизации ListBoxItem. Возможно и так: решать-то они решали, но затратив в разы больше времени, чем на тупой перекодинг OnPaint — и чего тут расхваливать?
S>В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом.
Мы же сравниваем не чего ВПФ лучше, а чего он хуже — хуже нормального, нативного кода в отрисовке. Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
Здравствуйте, sunshine, Вы писали:
>приступать что-то писать на WPF имхо, не стоит, не прочитав прежде толстенькую книгу про него
Именно так и было сделано, предваряло серьезное изучение и весьма глубокое копание.
S>Однако, после того как пощупаешь это дело, WinForms воспринимается уже просто технологией каменного века
Это в случае, если вам нужно от UI что-то типа "плетется курсор мыши — а под ним автоматом мигают кнопки, красиво". А если требования к UI бизнес, то мне это все не важно. Мне важно, что там нет нормального датагрида, например. Можно захостить винформовский, но это же уродство. Вот что является ключевым. Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. Просто такое использование в этой технологии изначально не предполагалось.
S>На WPF можно быстро и элегантно сделать такие хитрые вещи, которые на WinForms заняли бы в разы больше времени
Безусловно. Огромное количество прекрасных автоматических механизмов.
RT>>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой. G>100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
G>Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel. G>В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
G>Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
Ситуация складывалась аналогично. В итоге получили облегченный Excel (графики, формулы, автофильтры, привязка к различным источникам данных,печать, эспорт в Excel ).
Все это обошлось в 2 мульена. Пользователи довольный, + получили полность лицензионно чистый продукт.
Здравствуйте, belnetmon, Вы писали:
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
У меня в решении этой задачи вообще нет кода. А у тебя?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, RadmirT, Вы писали:
RT>>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
G>Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
G>При таком кол-ве можно громадные скидки выбить, от 50%.
Из за единственной функции "возможность отображать данные на нерегулярной сетке" покупать Excel. Это как забивать микроскопом гвозди.
Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой.
Здравствуйте, RadmirT, Вы писали:
RT>А что еше нужно элементу управления который отображает таблицу а ля Excel, и которому не нужны анимация, эффект aero, 3D и прочие няшки?
А что, все программы в мире только и делают, что используют "элемент управления который отображает таблицу а ля Excel"? Этим же WPF не ограничивается. К чему этот стеб про "няшки"? Я никоим образом не имел ввиду ни анимацию, ни aero, ни 3D. Главным образом WPF — это грамотный компоновщик и привязка данных. И потом, если не заметил, то я подтвердил
, что при большом количестве примитивов есть тормоза. Но эту проблему можно попробовать решить частичным рисованием: в области, большей чем видимая, но меньшей, чем огромный компонент.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, me2, Вы писали:
me2>>Первое время все казалось сложным, но стоит только разобраться — не так и страшно.
M>А по-моему, всё ровно наоборот: сначала смотришь примитивные примеры — о, да это как два байта переслать! А как начинаешь разбираться — боже мой... чесание левого уха правой рукой, в которую загипсован чесальщик спины для левой ноги. Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски. Авторское "Drat and double drat!" достаточно хорошо выражает общую мысль. Нет, не читайте решение — сначала решите сами, а потом спросите себя — стоило ваше время того тривиального эффекта, что вы достигли?
Да не так страшно. Если про ItemsPanelTemplate — вполне нормальное поведение. Список может быть совершенно любым, соответсвенно контейнер элементов должен меняться. Свойство horizontal|vertical — частный случай, так что выносить его в элемент управления не совсем правильно (список может быть вообще "каруселькой"). Про WrapPanel — туда же. У них там изначально все очень абстрактно, вот и получаются всякие якобы не очевидные вещи. Но если поработать с технологией — быстро привыкаешь и становится вполне логичным такое поведение (или просто не обращаешь внимания)
Здравствуйте, 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 его уже юзает
Скажу по собственным ощущениям. С WPF работаю уже три года, очень приятно, что технология не ставит ограничений.
Другой вопрос, что требуется кардинальная перестройка мышления и подхода к разработке UI. А на это, как выясняется,
способны далеко не все. Будущее у WPF есть, причем, с моей точки зрения, достаточно радужное, ибо в 4-й версии поправили
косяки со шрифтами, которые немало доставляли в свое время.
З.Ы. Тут на форуме периодически пробегают вопросы о том, как подменить элементы в готовом шаблоне и т.д. С моей точки зрения,
подобные извраты — следствие неудачной архитектуры приложения. Сам таким страдал года 2,5 назад. Потом стал писать по-другому
и надобность в подобных извратах отпала.
Здравствуйте, MxMsk, Вы писали:
MM>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Здравствуйте, 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>Просто такое использование в этой технологии изначально не предполагалось.
Тогда делай как предполагалось, возможностей уйма.
У меня 2008 студия, WPF тулкит и грид оттуда — ужасен
B>>Мне важно, что когда я вручную строю меню, там тоннами глюки, просто вагонами. G>Что значит "строю вручную"?
Динамическая генерация UI из разных критериев. То есть меню и наполнение живут в метаданных, откуда загружаются и так строится UI.
G>Тогда делай как предполагалось, возможностей уйма.
Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него.
Здравствуйте, 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
RT>1. Куча столбцов/колонок RT>2. Границы ячеек могут быть различной толцишы и различного цвета RT>3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены RT>4. Куча теста в ячейках написанных различными шрифтами RT>Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается.
И каким образом вы решали это на wpf? Надеюсь не рисовали на Canvas?
Здравствуйте, LF, Вы писали:
RT>>1. Куча столбцов/колонок RT>>2. Границы ячеек могут быть различной толцишы и различного цвета RT>>3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены RT>>4. Куча теста в ячейках написанных различными шрифтами RT>>Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается. LF>И каким образом вы решали это на wpf? Надеюсь не рисовали на Canvas?
Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry.
В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics.
RT>Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry. RT>В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics.
А вот у этих ребят получилось http://xceed.com/Grid_WPF_Demo.html http://devexpress.com/Products/NET/Controls/WPF/Grid/
хотелось бы посмотреть на аналогичные решения на базе WinFoprms.
Здравствуйте, LF, Вы писали:
RT>>Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry. RT>>В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics. LF>А вот у этих ребят получилось LF>http://xceed.com/Grid_WPF_Demo.html LF>http://devexpress.com/Products/NET/Controls/WPF/Grid/ LF>хотелось бы посмотреть на аналогичные решения на базе WinFoprms.
1. У них ОТЛОЖЕННЫЙ скролинг.
2. Это обычный DataGrid т.е. нельзя задать нерегулярную сетку.
RT>1. У них ОТЛОЖЕННЫЙ скролинг.
Нет, вожу ползунком — содержимое перерисовывается.
RT>2. Это обычный DataGrid т.е. нельзя задать нерегулярную сетку.
Может быть в данных конкретных нельзя, что не факт, может этого нет просто в примерах.
Главное тут, что технология позволяет делать сложный UI, а то что не реализовали нерегулярную сетку — дело времени и запросов пользователей.
LF>Может быть в данных конкретных нельзя, что не факт, может этого нет просто в примерах.
Нет нельзя совсем. Перед тем как начать делать свою собсвенную реализацию мы перепробывали кучу компонентов.
В итоге не один WPF или не обеспечивал достаточной скрости или не позволял реализовавать spreadsheet
LF>Главное тут, что технология позволяет делать сложный UI, а то что не реализовали нерегулярную сетку — дело времени и запросов пользователей.
Для бизнес приложений главное не "няшки" а адекватная скрость работы.
RT>Нет нельзя совсем. Перед тем как начать делать свою собсвенную реализацию мы перепробывали кучу компонентов. RT>В итоге не один WPF или не обеспечивал достаточной скрости или не позволял реализовавать spreadsheet
Можно реализовать свой. Я правильно понимаю, что в представленных примерах не устраивает лишь отсутствие нерегулярной сетки?
RT>Для бизнес приложений главное не "няшки" а адекватная скрость работы.
Не увидел тормозов в представленных примерах и выглядит красиво, начальство должно быть довольно.
Здравствуйте, LF, Вы писали:
LF>Можно реализовать свой. Я правильно понимаю, что в представленных примерах не устраивает лишь отсутствие нерегулярной сетки?
Эта "мелочь" является камнем преткновения.
Размещение приметива в WPF довольно затратная операция.
например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, Codechanger, Вы писали:
RT>>>По поводу скорости работы я с тобой не согласен. RT>>>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
C>>UseCase в студию.
RT>Рисуем Grid а ля Excel
Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
G>Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
G>Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
RT>Размещение приметива в WPF довольно затратная операция.
Я в курсе, поэтому создание элементов надо минимизировать и применять трансформацию уже к существующим.
RT>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms.
Какое это имеет отношение к нерегулярной сетке?
RT>>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms. LF>Какое это имеет отношение к нерегулярной сетке?
Прямое. Если сетка у нас регулярная. То мы вполе можем обойтись трансформацииями.
Для нерегулярной сетки алгоритм будет "чуть сложнее". Нуюно будет еще удалять/добавлять примитивы.
RT>Прямое. Если сетка у нас регулярная. То мы вполе можем обойтись трансформацииями. RT>Для нерегулярной сетки алгоритм будет "чуть сложнее". Нуюно будет еще удалять/добавлять примитивы.
Замечательно, а теперь простой Grid c RowSpan и ColumnSpan позволяет строить нерегулярную сетку.
В чем сложности, зачем обязательно надо отрисовывать через примитивы?
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
G>>Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
G>>Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
RT>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
При таком кол-ве можно громадные скидки выбить, от 50%.
Здравствуйте, LF, Вы писали: LF>Замечательно, а теперь простой Grid c RowSpan и ColumnSpan позволяет строить нерегулярную сетку. LF>В чем сложности, зачем обязательно надо отрисовывать через примитивы?
В этом случае мы молучаем еще более сильные тормоза.
Т.к. при каждом изменении положения ползунка. WPF будет "образмеривать" ВСЕ дерево визуальных объектов. Это в разы затратнее чем добавление нового примитива.
Здравствуйте, RadmirT, Вы писали:
RT>Размещение приметива в WPF довольно затратная операция. RT>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже самое сделать в WinFroms.
Я пробовал в WPF, всё нормально pan'ится, scroll'ится, zoom'ится. А что там в WinForms?
Q>Я пробовал в WPF, всё нормально pan'ится, scroll'ится, zoom'ится. А что там в WinForms?
После того как эти примитивы разместятся, то все летает. А вот сам процесс размещения ужасно тормозной.
А для нерегулярной сетки приходится постоянно добавлять/удалять примитивы.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, RadmirT, Вы писали:
RT>>>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
G>>Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
G>>При таком кол-ве можно громадные скидки выбить, от 50%.
RT>Из за единственной функции "возможность отображать данные на нерегулярной сетке" покупать Excel. Это как забивать микроскопом гвозди.
Сходу могу сказать что еще захотят пользователи:
1)Печать как в excel
2)быстро строить графики\отчеты
3)экспорт в сам excel и загрузку из него
4)Выделять и копировать ячейки как в excel
RT>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой.
100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel.
В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
Здравствуйте, Qbit86, Вы писали:
Q>Причём здесь создаются тяжеловесные Shape'ы, а можно рисовать более низкоуровневые freeze'анутые StreamGeometry, например.
Согласен. Роботает довольно быстро. Но..
1. Все равно медленне чем WinForms
2. Попробуй для эксперимента используя VirtualCanvas размещать на экране сразу 100 элементов. Для Excel это только линии сетки.
Если же отрисовывать еще границы ячеек разной толщины и цвета + использовать разнообразную заливку ячеек + еще успевать рисовать текст. То получается около 1000 эелементов.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
RT>>>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой. G>>100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
G>>Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel. G>>В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
G>>Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
RT>Ситуация складывалась аналогично. В итоге получили облегченный Excel (графики, формулы, автофильтры, привязка к различным источникам данных,печать, эспорт в Excel ). RT>Все это обошлось в 2 мульена. Пользователи довольный, + получили полность лицензионно чистый продукт.
То есть таки excel на рабочих машинах стоял... А можно было гораздо меньшими проблемами в UI обойтись взяв excel изначально.
Здравствуйте, gandjustas, Вы писали:
G>То есть таки excel на рабочих машинах стоял... А можно было гораздо меньшими проблемами в UI обойтись взяв excel изначально.
Excel стоял но на очень ограниченном количестве рабочих мест около 500. На остальных рабочих станциях либо ничего не стояло либо стоял ОpenОffice.
Здравствуйте, Qbit86, Вы писали:
Q>Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
ИМХО если мы рисуем все ручками с помошью Drawing нафига нам вообще нужен WPF. генрим в памяти bmp а потом ввыводим его на экран.
Здравствуйте, RadmirT, Вы писали:
Q>>Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
RT>ИМХО если мы рисуем все ручками с помошью Drawing нафига нам вообще нужен WPF. генрим в памяти bmp а потом ввыводим его на экран.
Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
Здравствуйте, Qbit86, Вы писали:
Q>Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
Это понятно. Но все это относительно легко делатся в WinForms. Пропадает самое главное — возможность использоваяния "красявости" WPF.
Здравствуйте, RadmirT, Вы писали:
Q>>Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
RT>Это понятно. Но все это относительно легко делатся в WinForms. Пропадает самое главное — возможность использоваяния "красявости" WPF.
Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
Здравствуйте, Qbit86, Вы писали:
Q>Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Здравствуйте, RadmirT, Вы писали:
Q>>Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
RT>Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Насчёт в «GDI+ быстрее, чем в DirectX» у меня есть большие сомнения. Примеры ведь в этой ветке были только с моей стороны.
Здравствуйте, RadmirT, Вы писали:
RT>Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Ну, если сравнивать только рисование прямоугольников, то может и нет никаких преимуществ
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, MxMsk, Вы писали:
MM>>У меня в решении этой задачи вообще нет кода. А у тебя?
J>О. Очень частое заявление от WPF'ников. Отсюда вопрос: J>а вы xaml за код не считаете ?? Его не нужно писать, не нужно поддерживать??
Это был троллинг В той задаче XAML простой получается по сравнению с тем, что придется ваять в GDI+. Поддержка его не составит труда.
Здравствуйте, RadmirT, Вы писали: RT>Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Примеры в студию. Будем, так сказать, отталкиваться от реальности.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, Codechanger, Вы писали:
C>>Примеры в студию. Будем, так сказать, отталкиваться от реальности.
RT>тут
Здравствуйте, RadmirT, Вы писали:
RT>Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Насчет проще — всё не так однозначно. Скажем, с текстом будет удобнее работать в WPF. Задавать шаблоны для ячеек тоже будет удобнее в WPF. Сама отрисовка сетки, возможно, проще да, но только до тех пор, пока визуальщина примитивна. Еще раз уточню, что я это написал о простоте, а не об эффективности.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, RadmirT, Вы писали:
MM>Насчет проще — всё не так однозначно. Скажем, с текстом будет удобнее работать в WPF. Задавать шаблоны для ячеек тоже будет удобнее в WPF. Сама отрисовка сетки, возможно, проще да, но только до тех пор, пока визуальщина примитивна. Еще раз уточню, что я это написал о простоте, а не об эффективности.
Абсольтно соглаен. Когда начинали проект именно эти веши склоняли нас к выбору WPF. Но к сожалению критерий "скорость" перевесила все аргументы за.
Здравствуйте, RadmirT, Вы писали:
RT>Я говорю что в конкретном случае, когда необходимо оперироват большим количеством примитивов,которые постоянно удаляются/добавляются, использования WinForms + GDI+ эффективнее чем WPF + DirectX
Поддерживаю. По логике вещей именно так и должно быть. Ведь чудес не бывает. Сейчас сам озадачен, стоит ли переводить свой редактор диаграмм из WinForms на WPF. Если отталкиваться от того, что элементов на диаграмме будет не так много, то можно и перевести. Но сейчас особый предмет моей гордости — это способность диаграммера сносно держать в динамически обновляемом состоянии более ста тысяч элементов одновременно на довольно стареньком пятилетнем ноутбуке с целероном и очень скромной интегрированной видеокартой. Отдаю себе отчет, что при переходе на WPF и Silverlight такая [не очень-то и нужная] способность пропадет, как пить дать.
Re[7]: Будущее WPF?
От:
Аноним
Дата:
08.09.10 09:42
Оценка:
G>>>Тогда делай как предполагалось, возможностей уйма. B>>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него. G>Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
Здравствуйте, Аноним, Вы писали:
G>>>>Тогда делай как предполагалось, возможностей уйма. B>>>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него. G>>Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
А>а можно подробней описать процесс?
Здравствуйте, RadmirT, Вы писали:
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
WPF — это не графика, это другой подход к построению пользовательского интерфейса (Data Driven UI). Для рисования у вас есть GDI, GDI+, Direct2D, DirectX. WPF использует DirectX, а не пытается его собой заместить.
Здравствуйте, MozgC, Вы писали:
MC>Глянул вакансии — на данный момент не сильно востребован.
Я тоже глянул на дайсе. Для WPF в два раза больше вакансий, чем для винформс.
Здравствуйте, olegkr, Вы писали:
MC>>Глянул вакансии — на данный момент не сильно востребован. O>Я тоже глянул на дайсе. Для WPF в два раза больше вакансий, чем для винформс.
Я тоже глядел как раз на дайсе по запросу ".NET + C#" и вручную просматривал тексты вакансий. Просмотрел 60-80 вакансий — по WinForms чуть-чуть больше чем по WPF.
Здравствуйте, MozgC, Вы писали:
MC>Я тоже глядел как раз на дайсе по запросу ".NET + C#" и вручную просматривал тексты вакансий. Просмотрел 60-80 вакансий — по WinForms чуть-чуть больше чем по WPF.
Не надо гадать на пальцах wpf — 724 results winforms — 410 results
Факт заключается в том, что винформс весьма активно заменяется wpf
Здравствуйте, belnetmon, Вы писали:
B>Здравствуйте, MxMsk, Вы писали:
MM>>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Вот обычный ListBox с кастомным ItemTemplate. Биндится на List<T> из итемов. Правда это Silverlight 4, а не WPF, но не суть.
Давай такое же на WinForms. Всё очень просто по сравнению с WinForms.
Здравствуйте, IT, Вы писали:
IT>Технология отличается чрезвычайной гибкостью, но при этом весьма высоким порогом вхождения.
Я бы этот порог нарисовал примерно как параболоиду — вначале вроде бы всё легко, но как только нужны средней сложности кастомизации, порог резко взлетает вверх. Причём поднятие по графику не умаляет сложности (график-то бесконечный! ), т.к. написание каждого нетривиального темлита превращается в разработку шаттла с нуля.
IT> Скорее всего компании, занимающиеся UI компонентами, наклепают компонентов попроще и подоступнее в использовании и будет всем счастье.
Вот, собсно, и ответ — технология "натянута на рынок", сильно завышая требования к разработчикам. Что-то стало гибче (как всегда, не то, что нужно), но тупой перенос "кода" в "декларации" родил ужа-с-ежом — вычурные, громоздкие конструкции, заменяющие трёхстрочный код. На мой взгляд, МС опять выдала "огонь и движение", причём неслабый такой огонь. Хочу обратно в мир ВыньФормс!
Здравствуйте, matumba, Вы писали:
M>Вот, собсно, и ответ — технология "натянута на рынок", сильно завышая требования к разработчикам. Что-то стало гибче (как всегда, не то, что нужно), но тупой перенос "кода" в "декларации" родил ужа-с-ежом — вычурные, громоздкие конструкции, заменяющие трёхстрочный код. На мой взгляд, МС опять выдала "огонь и движение", причём неслабый такой огонь. Хочу обратно в мир ВыньФормс!
Имея довольно таки не плохой опыт работы с WinForms (вплоть до создания своих элементов управления с интеграцией в дизайнер форм), сейчас (после Silverlight) возвращаться на него очень даже не охота. Первое время все казалось сложным, но стоит только разобраться — не так и страшно. Хотя, может сыграл момент ограниченности Silverlight. WPF более богат возможностями, что поначалу может немного пугать
p.s. При большом желании можно так же все в коде писать. Хотя если привыкнуть к XAML, то оказывается очень удобно. Можно так же посмотреть на Expression Blend в плане рисования UI
Здравствуйте, MozgC, Вы писали:
MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
WPF уже давно прижился. Он очень хорошо подходит для написания всяких бизнес приложений. Люблю его за то, что UI легко кастомизируется и приложение выглядит современным, при этом не приходится использовать всякие левые контролы усложняющие продукт: 90% необходимого уже есть. В сочетании c MVVM продукт получается очень гибким и грамотно структурированным, что полезно с точки зрения дальнейшего развития.
Ложка дегтя:
* Производительность, обходится написанием критичных компонент на C++
* Отсутствие единого подхода к разработке, кто-то пишет обработчики событий в View классе потому-что студия сама провоцирует к этому, кто-то во ViewModel классе, кто-то настраивает UI из кода, кто-то из XAML, в результате может быть бардак
* Тяжелый deployment
* Бывают глюки на слабом или старом железе
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, henson, Вы писали:
H>>* Тяжелый deployment O>Поподробнее, плиз. Там же вроде все должно быть примитивно и просто.
Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс.
Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой. Client Profile поменьше, но все равно больше .NET 2.0 с WinForms
Здравствуйте, henson, Вы писали:
H>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс. H>Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой.
Здравствуйте, henson, Вы писали:
H>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере.
Для интранетовских бизнес приложений это не очень актуально. Особенно, если софт в конторе распространяется и ставится централизованно.
Если совсем критично, что сильверлайт спасет демократию.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, henson, Вы писали:
H>>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. O>Для интранетовских бизнес приложений это не очень актуально. Особенно, если софт в конторе распространяется и ставится централизованно. O>Если совсем критично, что сильверлайт спасет демократию.
Однозначно, сильверлайт еще предпочтительней в плане Security
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, henson, Вы писали:
H>>Ну я к тому что с появлением WPF .NET Framework дистрибутив прилично вырос в размере. Это может быть не напрямую связано с WPF, но еще один фактор усложняющий процесс. H>>Ибо сказать клиенту, что мы вот тут вам сейчас качнем быстренько 100 мегабайт может быть непростительной ошибкой.
Q>dotnetfx35.exe — 231.4 Mb Q>dotNetFx40_Full_x86_x64.exe — 48.1 Mb
Зачем сравнивать размер полного Framework и Client Profile?
Здравствуйте, matumba, Вы писали:
M> Вот вам простейшая задача, обратите внимание "как всё просто" и... абсолютно неочевидно, переусложнённо, череззаборногузадерищенски.
Проблема не столько в архитектуре WPF, сколько в абсолютно долбанутых на всю голову авторов дефолтных шаблонов. Увы, практически любая попытка их изменить неизменно заканчивается или вознёй с visual tree, или копипастом всего шаблона с прилегающими стилями и правкой всего с 0.
Если не нравится решение по ссылке, можно добавить такой костыль:
В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом. Такое ощущение, что разработчики специально убирали фичи, которые на первый взгляд незаметны, но их отсутствие сильно усложняет жизнь
Здравствуйте, matumba, Вы писали:
M>Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
Вы однозначно не пробовали играться с винформовскими девэкспрессами. Пара строчек стиля в XAML у девекспресса регулярнейше превращается в пару-тройку классов.
M>Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей...
Много чего. Особенно если сравнивать с глюками винформса и с кастомизацией TreeView/ListView. Спасибо, накушался.
M> Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
Ок. Простейшая задача. Прибиндьте TreeView к источнику данных. С нормальной производительностью — не перерисовывая всё дерево на каждое изменение коллекции. Сколько у вас уйдёт?
Приммер 2 — заказчик хочет в это дерево добавить экспандер или попап (он сам ещё не определился). Или лишнюю кнопочку на выделенном элементе. Или выравнивание TreeView по правому краю. И да, когда вместо того, чтобы объяснять почему хотелки заказчика фигня, и что только на прототип уйдёт пара дней, ты просто показываешь ч/з 10-20 минут прототип — это круто
M>Ты так реально считаешь? А мне кажется, что "сишарп", превращённый в архимудаические "атрибуты" — это и есть глобальное заблуждение авторов WPF. Шаблоны можно написать любые, но я сомневаюсь, что они смогут покрыть все случаи употребления. А код — мог бы...
Чет троллингом пахнет слегка.
M>Именно. Поэтому я как-то недоумеваю (мягко говоря) на расхваливателей WPF — либо им заплатили много долларей либо они не решали ничего, сложнее кастомизации ListBoxItem. Возможно и так: решать-то они решали, но затратив в разы больше времени, чем на тупой перекодинг OnPaint — и чего тут расхваливать?
Решали, решаем и будем решать. Например, панель навигации как в Outlook.( снизу там такая есть, где почта и т.д.). На WPF это один небольшой класс плюс два шаблона. Во что это выльется на ВинФормах, честно говоря, не знаю.
S>>В то же время, чтобы прочувствовать все приятные мелочи WPF, достаточно поработать с 3м сервелатом.
M> Мы же сравниваем не чего ВПФ лучше, а чего он хуже — хуже нормального, нативного кода в отрисовке. Причём если подумать над архитектурой (этакий WinForms-2), можно грамотно скомбинировать стили и контролы-примитивы, комбинация которых (даже несколько контролов) будет решать задачу без простыней кода.
В общем, если по теме, то Матумба ниасилил. В силу каких причин, не берусь судить. Тут может быть совокупность нескольких факторов. Как минимум не стоит подходить к WPF с мерками WinForms.
Если нам не помогут, то мы тоже никого не пощадим.
