Здравствуйте, barn_czn, Вы писали:
_>Намучились и натра..сь со стандартным WPF TreeView, потом натрах..сь со своим наследуемым от TreeView. Теперь хотим запилить полностью свой, может быть даже пожертвовав стандартными парадигмами WPF (вроде того чтоб не юзать ItemsControl).
VC>Ну ты уже написал что DevExpress не осилил. Но я все таки подеюсь
Чувак, поднимай ЧСВ в другом месте пож-та. DevExpress проживет и без меня, нравится — юзай на здоровие.
VC>Был длительный опыт потрахахаться и дописывать костыли к самописным контролам притащенными всякими энтузазистами покопипастить из интеренета "бесплатные" контролы, потом за месяц все поменял на DevExpress с блекджеком и шлюхами встроенными в DevExpress.
Здравствуйте, barn_czn, Вы писали:
_>Про DevExpress очень плохо думаю.. ну оочень.
Избегаю этот "китайпром". Эти ребята думают, что если в контрол насовать тысячу пропертей вида "ЦветРамкиСлева", "ШрифтДляПолосочкиВнизу", то это как-то делает их контролы лучше. Плюс, бесконечные апдейты, breaking changes, etc. Отказались от этого позорища ИТ и теперь бед не знаем.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Jack128, Вы писали:
K>>>выровнять заголовок GroupBox вправо
J>>Точно,...И поперла простота, тут и наследники в перекрытием OnPaint, и расположение своего Label'а поверх групбокса, ну и отбивка пробелами, куда ж без неё..
K>Вы немного не о том. WPF появилась много позже WinForms и у прогеров был громадный надел типичных задач, которые клоуны из M$ просто... проигнорировали. А если б сразу подумали, то сейчас не пришлось бы колхозить стили вместо установки простейшего атрибута. И дело не в этой конкретной задаче, а самом принципе — то, что всё можно накастомайзить, НЕ ДОЛЖНО быть поводом для "мы тут едва запилили проперть, кому надо — сами оттемплэйтят!". WPF уже из коробки должен быть максимально удобным.
K>Кстати, то, что ЗА СТОЛЬКО ЛЕТ WinForms так и остался УГ — тоже вина M$. Там ТЫСЯЧИ недоделок и ограничений, но нет... нафига нам это улучшать — мы лучше в Облачка играть будем! Вообще непонятно, за что команда WinForms получала деньги последние 15 лет.
Я не говорю, что wpf идеален, а xaml так вообще — убожество. НО. Если выбирать из Wpf vs WinForms — то для меня выбор очевиден.
Вообще самое главное в программировании — это возможность разбить задачу на части, а потом из этих частей собрать сложное решение.
И вот с этим моментом у Wpf всё худо бедно хорошо. А у WinForms — плохо. Очень плохо. Чуть что — берем в руки Graphics и ручками, ручками, ручками.
T>>бу-га-га, ежики до сих пор трахаются с кактусом
T>>но трахать себя в коленку это дешевле, чем заплатить пару тыс. баксов за труд профессионалов !
_>Надо полагать профессионал это ты )). _>Да все прекрасно не переживай, запросы на фичи просто растут.
пара тыс. баксов- это цена лицензий на все имеющиеся на рынке коммерческие контролы, профессионалов немного, на самом деле: syncfusion, grapecity, devexpress, telerik, infragistics, но трахать кактусы некоторым доставляет удовольствие
Здравствуйте, barn_czn, Вы писали:
VC>>Ну ты уже написал что DevExpress не осилил. Но я все таки подеюсь
_>Чувак, поднимай ЧСВ в другом месте пож-та. DevExpress проживет и без меня, нравится — юзай на здоровие.
VC>>Был длительный опыт потрахахаться и дописывать костыли к самописным контролам притащенными всякими энтузазистами покопипастить из интеренета "бесплатные" контролы, потом за месяц все поменял на DevExpress с блекджеком и шлюхами встроенными в DevExpress.
_>Как говорится совет вам да любовь .
Теперь понятно зачем тебе свой полностью — у тебя еще и с ЧСВ проблемы
Здравствуйте, barn_czn, Вы писали:
_>Намучились и натра..сь со стандартным WPF TreeView, потом натрах..сь со своим наследуемым от TreeView. Теперь хотим запилить полностью свой, может быть даже пожертвовав стандартными парадигмами WPF (вроде того чтоб не юзать ItemsControl).
Прекрасно вас понимаю. У меня тоже неплохой стаж вендописания, но вот осилить "свой контрол с нуля" в WPF — только начинаю и от той беспросветной архитектуры впадаю в уныние. По-моему, WPF хорош только для одного — кастомайзить существующие вещи. Писать что-то самому — проще застрелиться. Это ещё раз доказывает, что WPF проектировали через анус, построив в результате неуклюжего монстра. НЕ МОЖЕТ красивая и простая идея "декларативного интерфейса" быть такой ублюдочно сложной и неуклюжей, как это сделано в WPF!
_>Фичи которые надо _>- мульти селекшен _>- встроеный редактор в ноду (переименование как пример)
_>- асинхронность загрузки, ленивость
Вот не надо с этим торопиться!! Я уже проклинаю тех индусов, которые вкорячили эту ленивость вдоль и поперёк в WPF — теперь вместо простых решений "взял контрол айтема и сменил проперть", ты корячишься с какими-то ItemContainerGenerator, которые тебе в пень не упёрлись.
Принцип прост: если у тебя в UI очень много элементов/больших списков — сокращай, это твой косяк проектирования. НИКТО не читает тысячу элементов. А разумное количество (10-100) ПРЕКРАСНО обрабатывается безо всяких тормозов даже при отсутствии "ленивостей".
_>- фильтрация, сортировка
шта?? В дереве?
_>- поддержка шаблонов и стилей
та... мальчикам на поиграть. Мы 10 лет слушали MS как важно делать/сохранять СТАНДАРТНЫЙ внешний вид контролов, чтобы юзер не мучался с вашими фантазиями и быдлятскими вкусами ("тёмные темки", ага!), а просто видел стандартный контрол и делал стандартные действия. (и в этом я MS поддерживаю)
А если так важно всё же влезть в отображение элемента — запросто: раздавайте API для отрисовки элемента и там уже творите что угодно.
_>Да, знаю что попахивает велосипед-строением, но другого выхода не вижу.
Не стыдно писать велосипеды. Потому что будь существующие контролы — грамотно спроектированными, велосипедить не пришлось бы!
_>Есть у каво какие советы, напутствия (кроме "в добрй путь"), опыт ?
WinForms. Запилите своё дерево, с блэкджеком и бранчами, а потом WindowsFormsHost — почему бы и нет?
WPF тут совсем не причем.
Нетривиальные контролы типа TreeView, которые еще хочется переиспользовать в разных местах или даже проектах,
вообще очень непросто даже специфицировать.
Забудь про технологию, и просто продумай интерфейс того же TreeView.
Уже на этом этапе замучаешься, особенно если захочешь сделать универсальный контрол.
Контролов с единственным методом "DoWhatMyCustomerNeed()" мне пока не попадалось
Все остальное — это тот или иной компромис между универсальностью и зашитой логикой на один единственный случай.
Проблемы идут оттуда, а не от WPF или еще какого фреймворка.
А так писать свои контролы на WPF вообще не проблема, если есть четкое понимание как этим должны пользоваться.
Над нормальной виртуализацией и асинхронный подгрузкой данных конечно придется помучаться,
но не более чем в любых других фреймворках.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, barn_czn, Вы писали:
_>>Намучились и натра..сь со стандартным WPF TreeView, потом натрах..сь со своим наследуемым от TreeView. Теперь хотим запилить полностью свой, может быть даже пожертвовав стандартными парадигмами WPF (вроде того чтоб не юзать ItemsControl).
K>Прекрасно вас понимаю. У меня тоже неплохой стаж вендописания, но вот осилить "свой контрол с нуля" в WPF — только начинаю и от той беспросветной архитектуры впадаю в уныние.
Я в году 1996 или в 1997 делал контролы на родном Windows API, а также OwnerDraw, когда заказчик хотел "оригинальный интерфейс". Всё это дело шустро работало под Windows 95 на 486 процессоре с 4МБ памяти. 4 мегабайта! Тут в соседней ветке ноутбук минимальный подбирают с 16 ГБ.
К WPF у меня отвращение... увы, поэтому я бы унаследовал от TreeView, добавил бы в Node свои данные (хэш или указатель) и делал так же OwnerDraw, но с Windows GDI+ для слоёв, прозрачности и др. эффектов.
Здравствуйте, DarthSidius, Вы писали:
DS>Здравствуйте, barn_czn, Вы писали:
_>>Ну зря вы так про WPF. В целом он вполне логичен и красив.
DS>Ога. Особенно наследование. Чтобы внести небольшое изменение, порой приходится переписывать всю простыню ControlTemplate
И что? В хваленом WinForms вы вообще ничего не можете изменить. Может быть стандартные контролы WPF недостаточно гибкие, но на более низком уровне WPF куда поприятнее винформсов.
И кстати, для всех, проблема топика решена. TreeView написан где то за неделю, со своим специфическим набором фич под конкретный проект. Не так уж это и страшно оказалось.
Здравствуйте, Kolesiki, Вы писали:
K>Это я ещё не писал примеры, где вообще без ШАБЛОНА КОНТРОЛА не обойтись(!!). Т.е. вместо решения бизнес задач ты занимаешься тем, что перекраиваешь существующие контролы только потому, что "всё кастомайзится" и ленивые индусы спихнули эту работу на тебя. Это вообще как?
Код для решения бизнес-задачи должен работать без всяких контролов, без пользовательского интерфейса вообще. То есть, две разных задачи совершенно — контролы писать и бизнес-логику лабать.
WPF тем и ценен, что можно всё перекроить. И не надо при этом стопицот свойств поддерживать типа HeaderAlign! Вместо этого мы имеем лаконичную систему свойств, шаблонов данных и стилей, через которые реализуется любая хотелка. А у кого не получается, ну извините — вам навстречу пошли в UWP, понапихали "удобных" свойств, и это такое УГ — теперь, чтобы что-то поменять, надо писать кучу кода и иногда обнаруживать, что какая-то фигня захардкожена в коде контрола и через стиль ничего переделать не получится.
Намучились и натра..сь со стандартным WPF TreeView, потом натрах..сь со своим наследуемым от TreeView. Теперь хотим запилить полностью свой, может быть даже пожертвовав стандартными парадигмами WPF (вроде того чтоб не юзать ItemsControl).
Фичи которые надо
— мульти селекшен
— встроеный редактор в ноду (переименование как пример)
— асинхронность загрузки, ленивость
— фильтрация, сортировка
— поддержка шаблонов и стилей
Да, знаю что попахивает велосипед-строением, но другого выхода не вижу.
Есть у каво какие советы, напутствия (кроме "в добрй путь"), опыт ?
Здравствуйте, barn_czn, Вы писали:
_>Заказчик любит сильные кастомизации, поэтому хочу понять на сколько это затратно, иметь свой неповторимый TreeView.
ТОлько они его уже больше 10 лет пилят. У вас сходу лучше не получится. Ну или еще одно направление разработки откроете
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, barn_czn, Вы писали:
BE>>>У DevExpress или Telerik ничего подходящего нет?
_>>Про DevExpress очень плохо думаю.. ну оочень. Откровенно непродуманй API, баги баги баги..
bnk>DevExpress вообще-то очень хорошее решение, из тех что вообще есть на рынке. Ты его точно открывал, или повторяешь то что "одна баба сказала"?
Открывал раза 3 на разных проектах с интервалом 3-5 лет. Как оно было гвном, так и осталось.
Впрочем о вкусах не спорят.
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, barn_czn, Вы писали:
_>>Заказчик любит сильные кастомизации, поэтому хочу понять на сколько это затратно, иметь свой неповторимый TreeView.
BE>ТОлько они его уже больше 10 лет пилят. У вас сходу лучше не получится. Ну или еще одно направление разработки откроете
Вот этого и опасаюсь. И хочу послушать тех кто "открыл" таки.
Здравствуйте, barn_czn, Вы писали:
_>>>Заказчик любит сильные кастомизации, поэтому хочу понять на сколько это затратно, иметь свой неповторимый TreeView.
Ну если ты так говориш то ни в DevExpress ты не видел ее, или плохо понимаеш что такое кастомизация
BE>>ТОлько они его уже больше 10 лет пилят. У вас сходу лучше не получится. Ну или еще одно направление разработки откроете
_>Вот этого и опасаюсь. И хочу послушать тех кто "открыл" таки.
Ну ты уже написал что DevExpress не осилил. Но я все таки подеюсь
Был длительный опыт потрахахаться и дописывать костыли к самописным контролам притащенными всякими энтузазистами покопипастить из интеренета "бесплатные" контролы, потом за месяц все поменял на DevExpress с блекджеком и шлюхами встроенными в DevExpress.
Здравствуйте, takTak, Вы писали:
T>но трахать себя в коленку это дешевле, чем заплатить пару тыс. баксов за труд профессионалов !
Ну это скорее а к заказчику. Может ему разработчику каждый месяц по несколько килобаксов удобнее платить, чем один раз килобакс за библиотеку отдать (бюрократия в организациях и не такие финты может выдавать)
В этом даже может быть смысл, например если бюджет заказчика неограничен (гос. организация), или если заказчику хочется некие уникальные фичи в интерфейсе.
T>>но трахать себя в коленку это дешевле, чем заплатить пару тыс. баксов за труд профессионалов !
bnk>Ну это скорее а к заказчику. Может ему разработчику каждый месяц по несколько килобаксов удобнее платить, чем один раз килобакс за библиотеку отдать (бюрократия в организациях и не такие финты может выдавать) bnk>В этом даже может быть смысл, например если бюджет заказчика неограничен (гос. организация), или если заказчику хочется некие уникальные фичи в интерфейсе.
ну да, пол-года пилить какой-то там контрол, чтобы он работал только в одной единственной конфигурации — это благодатная среда: лет через 30 пиления гирь и до какого-нибудь девэкспрессовского или телериковского 20 летней давности будет дотягивать
T>>>бу-га-га, ежики до сих пор трахаются с кактусом
T>>>но трахать себя в коленку это дешевле, чем заплатить пару тыс. баксов за труд профессионалов !
_>>Надо полагать профессионал это ты )). _>>Да все прекрасно не переживай, запросы на фичи просто растут.
T>пара тыс. баксов- это цена лицензий на все имеющиеся на рынке коммерческие контролы, профессионалов немного, на самом деле: syncfusion, grapecity, devexpress, telerik, infragistics, но трахать кактусы некоторым доставляет удовольствие
С тобой проще согласится. Еслиб это было мое решение, я бы и стандартным обошелся наплевав на все плюшки и красявости. Devexpress — полное гвно. telerik наверно лучшее что есть.
T>>>>бу-га-га, ежики до сих пор трахаются с кактусом
T>>>>но трахать себя в коленку это дешевле, чем заплатить пару тыс. баксов за труд профессионалов !
_>>>Надо полагать профессионал это ты )). _>>>Да все прекрасно не переживай, запросы на фичи просто растут.
T>>пара тыс. баксов- это цена лицензий на все имеющиеся на рынке коммерческие контролы, профессионалов немного, на самом деле: syncfusion, grapecity, devexpress, telerik, infragistics, но трахать кактусы некоторым доставляет удовольствие
_>С тобой проще согласится. Еслиб это было мое решение, я бы и стандартным обошелся наплевав на все плюшки и красявости. Devexpress — полное гвно. telerik наверно лучшее что есть.
мне коллега один бывший нахваливал syncfusion, они его где-то в CAD- разработке использовали, он говорил, что "всё летало" и что все остальные коммерческие продукты были намного медленнее, devexpress хорош тем, что они быстро реагируют bug reports на и быстро их фиксят
Ну зря вы так про WPF. В целом он вполне логичен и красив. Отдельные контролы типа TreeView не достаточно гибки, да и то, на "взял и заюзал" пойдет.
ItemContainerGenerator — это да, какая то херь себе на уме которую фиг поймешь. Вот с ним я и боролся, понаставил костылей, а когда пришли новые запросы на фичи — тут не выдержад, почему и завел топик.
_>>- фильтрация, сортировка
K>шта?? В дереве?
Ну да, почему нет? Клиент хочет сортировку по имени, и чтобы при смене имени состояние дерева не сбрасывалось . ЗАчем? Да хрне знает, я исполнитель.
K> WinForms. Запилите своё дерево, с блэкджеком и бранчами, а потом WindowsFormsHost — почему бы и нет?
Нее.. винформсы то чем лучше? Я и на WPF просто откажусь от ItemsPreenter-ов и просто на уровне визуального дерева поработаю.
И MVVM конечно заюзаю, вот тут то WPF всяко лучше винформсов
Здравствуйте, barn_czn, Вы писали: _>Ну зря вы так про WPF. В целом он вполне логичен и красив.
На уровне хелловорлдов — да. На практике в него понапихали абсолютно посторонние вещи, которые к declarative UI имеют лишь косвенное отношение.
Логичен? Кхе-кхе... вы говорите или про какой-то другой WPF, или не копали его настолько, чтобы навсегда потерять дар речи.
Я пишу ни бог весть какой сложный софт, но вот на элементарных задачах я просто офигевал, сколько приседаний нужно сделать для элементарных действий.
Ну вот как пример
выровнять заголовок GroupBox вправо. ШТА?? То есть не headerAlign="right", а пиши свой полноценный лэйаут?? Ребят, вы в своём уме?
=========================================================================
Решил забайндить цвет колонки на проперть? Казалось бы...
<DataGridTextColumn Header="Expired" Binding="{Binding ExpiryDate}" Foreground={байндинг с конвертером} />
А на тебе поддых! Не будет лёгких путей, лезь в кишки и проводи хирургию внутренностей:
Серьёзно? Вот по таким типичным и тривиальным задачам я должен городить огород стилей? "Да иди ты в **опу, директор!" (ц) Масяня
Это я ещё не писал примеры, где вообще без ШАБЛОНА КОНТРОЛА не обойтись(!!). Т.е. вместо решения бизнес задач ты занимаешься тем, что перекраиваешь существующие контролы только потому, что "всё кастомайзится" и ленивые индусы спихнули эту работу на тебя. Это вообще как?
_>>>- фильтрация, сортировка K>>шта?? В дереве? _>Ну да, почему нет? Клиент хочет сортировку по имени, и чтобы при смене имени состояние дерева не сбрасывалось . ЗАчем? Да хрне знает, я исполнитель.
"Нет", потому что отфильтрованное дерево перестаёт быть деревом. (если узлы — однородны) Сортировка — тоже только в пределах siblings.
_>Нее.. винформсы то чем лучше?
ВСЕМ. Начиная ПРОСТОТОЙ и кончая скоростью.
_> Я и на WPF просто откажусь от ItemsPreenter-ов и просто на уровне визуального дерева поработаю.
Тут ничего кроме насмешливого "Удачи!" сказать не могу. Я понимаю, что принципиально можно сделать и на WPF, но вот удалять гланды через анус — не мой принцип. И писать тысячу строк кода ради одной финтифлюшки — тоже. _>И MVVM конечно заюзаю, вот тут то WPF всяко лучше винформсов
Ничем абсолютно. MVVM строго говоря вообще НИКАК не соотносится с WPF, это просто дизайн классов. Такое и в WinForms можно сделать легко — bindings взяли именно оттуда.
K>выровнять заголовок GroupBox вправо. ШТА?? То есть не headerAlign="right", а пиши свой полноценный лэйаут?? Ребят, вы в своём уме?
_>>Нее.. винформсы то чем лучше?
K>ВСЕМ. Начиная ПРОСТОТОЙ и кончая скоростью.
Точно, вот решение аналогичной задачи для WinForms, нужно не вправо, а в центр текст поместить. И поперла простота, тут и наследники в перекрытием OnPaint, и расположение своего Label'а поверх групбокса, ну и отбивка пробелами, куда ж без неё..
Здравствуйте, Jack128, Вы писали:
K>>выровнять заголовок GroupBox вправо
J>Точно,...И поперла простота, тут и наследники в перекрытием OnPaint, и расположение своего Label'а поверх групбокса, ну и отбивка пробелами, куда ж без неё..
Вы немного не о том. WPF появилась много позже WinForms и у прогеров был громадный надел типичных задач, которые клоуны из M$ просто... проигнорировали. А если б сразу подумали, то сейчас не пришлось бы колхозить стили вместо установки простейшего атрибута. И дело не в этой конкретной задаче, а самом принципе — то, что всё можно накастомайзить, НЕ ДОЛЖНО быть поводом для "мы тут едва запилили проперть, кому надо — сами оттемплэйтят!". WPF уже из коробки должен быть максимально удобным.
Кстати, то, что ЗА СТОЛЬКО ЛЕТ WinForms так и остался УГ — тоже вина M$. Там ТЫСЯЧИ недоделок и ограничений, но нет... нафига нам это улучшать — мы лучше в Облачка играть будем! Вообще непонятно, за что команда WinForms получала деньги последние 15 лет.
Здравствуйте, DarthSidius, Вы писали:
DS>Здравствуйте, barn_czn, Вы писали:
_>>Ну зря вы так про WPF. В целом он вполне логичен и красив.
DS>Ога. Особенно наследование. Чтобы внести небольшое изменение, порой приходится переписывать всю простыню ControlTemplate
Это ограничение Xaml, а не wpf. На C# тебе ничего не мешает залезть в визуальное дерево и что то там поменять частично. Ну там, хотя бы хедер групбокса сдвинуть в центр, как в задаче выше по ветке. Уж не знаю насколько идеологически это правильно, но работать будет
Здравствуйте, barn_czn, Вы писали:
DS>>Ога. Особенно наследование. Чтобы внести небольшое изменение, порой приходится переписывать всю простыню ControlTemplate
_>И что? В хваленом WinForms вы вообще ничего не можете изменить. Может быть стандартные контролы WPF недостаточно гибкие, но на более низком уровне WPF куда поприятнее винформсов.
"А в Африке дети вообще голодают". Я не хвалил винформс и не сравнивал с ним
Здравствуйте, bkat, Вы писали:
B>WPF тут совсем не причем.
Очень даже причем. Одно дело писать полностью абстрагированое чтото и к нему слой биндинга. Другое — все таки фреймворк ориентированое чтото.
Даже на уровне типов, тот же Brush брать под Background, — уже упрощение. Dependency properties, стили — готовая инфраструктура решает кучу проблем.
B>Нетривиальные контролы типа TreeView, которые еще хочется переиспользовать в разных местах или даже проектах, B>вообще очень непросто даже специфицировать.
Да, есть проблема в удачном API. Я пошел по пути разделения на veiwModel и View. В VeiwModel спихнул биндинги на данные, состояние дерева (IsExpanded тот же).
Так что VeiwModel боле менее абстрагирована от WPF. И сама вьюха в виде TreeControl, принимает вьюмодель.
До супер комерческого TreeView как до луны конечно, но прихоти заказчика решило и ладно.
Здравствуйте, barn_czn, Вы писали:
_>>>Ну зря вы так про WPF. В целом он вполне логичен и красив.
DS>>Ога. Особенно наследование. Чтобы внести небольшое изменение, порой приходится переписывать всю простыню ControlTemplate
_>И что? В хваленом WinForms вы вообще ничего не можете изменить.
Ну да. Как в известном "А у вас негров линчуют!". У ВыньФормса, безусловно, есть недостатки, но они никак не оправдывают недостатков WPF! Более того — благодаря "топорному" Win32 API, довольно просто понять, что откуда растёт и сделать у контрола желаемое поведение/вид. Разбирать же кишки шаблонов на 3 экрана и ковыряться в пропертях WPF нет никакого желания. Почему? Потому что если решение предполагает миллион приседаний, это не решение, а отстой. Причём писаный якобы профи за деньги.
_> Может быть стандартные контролы WPF недостаточно гибкие, но на более низком уровне WPF куда поприятнее винформсов.
Ровно наоборот — они как раз СЛИШКОМ гибкие там, где программисту особо ничего и не нужно. Благодаря чему простые кастомизации выливаются в ТОННУ усилий, совершенно не оправдывающих поставленную задачу. Для аналогии, как будто вам нужно заменить стекло в форточке, но для этого придётся разобрать всё окно до кирпичей. Оно того не стоит и явно спроектировано через зад.
_>И кстати, для всех, проблема топика решена. TreeView написан где то за неделю
Тут не недели важны, а сопровождаемость и гибкость. Если для улучшения контрола постороннему челу придётся неделю "вникать в тему" что и как у вас сделано, то вы просто размазываете изначальный геморой по времени и заранее обрекаете проект на "да к чёрту этот WPF, перепишем на WinUI!"
Здравствуйте, Jack128, Вы писали:
_>>>Нее.. винформсы то чем лучше? K>>ВСЕМ. Начиная ПРОСТОТОЙ и кончая скоростью.
J>Точно, вот решение аналогичной задачи для WinForms, нужно не вправо, а в центр текст поместить. И поперла простота, тут и наследники в перекрытием OnPaint, и расположение своего Label'а поверх групбокса, ну и отбивка пробелами, куда ж без неё..
Строго говоря, там сделана всего ОДНА вещь: переопределён OnPaint. Что для Win32 API вполне нормальная вещь. Т.е. WinForms контролы настолько простые, что не нужно долго смотреть, куда и что вкорячить. (а вы — напускатель тумана ради собственных аргументов — некрасиво работаете)
Понятно, что контрол можно было сделать намного гибче, просто клоуны, писавшие WinForms, преследовали цель "побырому завернуть Win32 в .NET", потому и получилось так похабно — всё смэпили 1:1 без разбора. Но факт остаётся фактом: влезть и улучшить WinForms контрол на порядок проще WPF'ного. Хотя казалось бы, должно быть наоборот.
Я не какой-то "идеологический противник" WPF — мне тоже нравится, когда можно беззаботно кастомайзить внешний вид мановением руки. Но вот это кастомайзенье — оно далеко не везде сделано грамотно, что превращает тривиальные задачи в целую гору препятствий. Этой темы не было бы вообще, будь WPF так хорош, как вы о нём поёте. Но в консерватории явно что-то не так, поэтому одни держат слона за хобот и считают, что всё просто, а другие уже всего слона излазили и сейчас где-то на этой стадии:
Здравствуйте, barn_czn, Вы писали: _>Здравствуйте, bnk, Вы писали: bnk>>Здравствуйте, barn_czn, Вы писали:
BE>>>>У DevExpress или Telerik ничего подходящего нет? _>>>Про DevExpress очень плохо думаю.. ну оочень. Откровенно непродуманй API, баги баги баги.. bnk>>DevExpress вообще-то очень хорошее решение, из тех что вообще есть на рынке. Ты его точно открывал, или повторяешь то что "одна баба сказала"? _>Открывал раза 3 на разных проектах с интервалом 3-5 лет. Как оно было гвном, так и осталось. _>Впрочем о вкусах не спорят.
А можно что поконкретнее? Просто интересно, уж лет 6 с перерывами пользую и никаких особых нареканий. Наоборот доволен.
Ну вот демка есть, что там конкретно Г.?
WinForms. Запилите своё дерево, с блэкджеком и бранчами, а потом WindowsFormsHost — почему бы и нет?
