Здравствуйте, Воронков Василий, Вы писали:
ГВ>>Всё, что касается особеностей мышления собеседника изначально неправомерно. ГВ>>В терминах ОО-языка можно записать массу всяческих мыслей. В терминах функционального языка — тоже. Язык — это только язык, он влияет до какой-то степени на выбор абстракций, но только до какой-то. Хм. По-моему, я уже где-то об этом говорил, совсем недавно.
ВВ>Для этого надо сначала признать, что именно есть эти самые "термины ФП", и они также отличны от того, что было раньше, как ООП от СП.
Странно. Раз есть функциональный (объектный, логический...) язык программирования (я имел в виду именно язык программирования), то безусловно есть и термины этого языка. Или ты хочешь сказать, что нужно непременно признать, что мышление человека происходит непосредственно в терминах языка?
ГВ>>Что-то у тебя всё перепутано. Хоть по словам оспаривай, ёлки зелёные. С одной стороны, я что-то не припомню, чтобы кто-то сводил FP-стиль к детерминированным функциям, а с другой — детерминированные функции вполне себе годятся на "pure FP".
ВВ>Забавная ситуация получается. С одной стороны "мы это все уже проходили" и "нас ничем не удивить", а уж какой-нибудь там "ломке мозгов" и говорить даже не приходится — типа это все по неопытности и незнанию. С другой стороны — налицо какое-то явное непонимание ФП, раз рождаются такие заявления о детерминированных ф-циях.
Я оговорился. Следует читать как: "...некоторые детерминированные функции вполне...".
ВВ>ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций.
Как это ни удивительно, но именно об этом я с самого начала и говорю.
ВВ>Именно поэтому гибридные языки, пытающиеся соединить в себе "the best of two worlds" и вызывают у меня некоторые сомнения.
Ну что тут поделаешь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Удивительное дело: что Lisp, что Prolog — простейшие языки. Их долго изучать невозможно в принципе. С другой стороны, они оказались настолько значимыми, что игнорировать их существование... Преподавателю... Э-э-э...
PD>>А с чего ты решил, что я игнорирую их существование ?
ГВ>Ну, значит, просто показалось, что ты их и в самом деле считаешь чем-то новым.
Новым ? Я ? Лисп и Пролог ? У меня дома по ним книжки лежат года так примерно 1985 года выпуска, прочитанные примерно тогда же
ГВ>ЭВМ 5-го поколения, ИМХО, не показатель. Этот проект блистательно провалился во всех ипостасях: что в Европе с Лиспом (или в Штатах с Лиспом играли, не помню), что в Японии. Пролог, ИМХО, хорош чистотой метода резолюций, который в нём реализован. Примерно как Лисп — он тоже привлекателен своей минимальностью.
Просто я не любитель маргинальных направлений. И Лисп и Пролог живут и не помирают, но отнюдь не составляют конкуренции мэйнфреймовским языкам. Поэтому с меня хватит знать, что они есть, и иметь представление, что они собой представляют, а больше не хочу.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Что за "выпиливание по пикселям"? В ГДИ+ вполне удобные примитивы, не припомню, чтобы я там что-то "выпиливал". ВВ>Попробуйте нарисовать какой-нибудь нетривиальный контрол — например, показывающий температуру в виде градусника. Или там скорость ветра в виде спидометра. Вот недавно такую хрень рисовали как раз. ВВ>На WPF — по трудозатрам — ну практически те же яйца.
В WPF эти трудозатраты будут сделаны один раз. Далее этот градусник можно будет засунуть куда угодно. В WindowsForms тебе придётся нарисовать градусник для контрола "градусник", градусник для кастомного типа столбцов в гриде, градусник внутри своего контрола TreeView, выпиленного целиком с нуля, ради того, чтобы он умел показывать градусник.
Здравствуйте, Sinclair, Вы писали:
S>>>Совершенно неудачно. См. bubbling/sinking как правильный механизм обработки сообщений. ВВ>>>>Да, "маппинг" окошек на контролы — это хорошо. S>>>Это отвратительно. ВВ>>Обосновать можешь? В контексте именно ГУИ-фреймворка. S>Конечно могу. Пример на пальцах: делаем композитный контрол. В идеологии окошко=контрол он обязан иметь оконный хендл, а все его компоненты обязаны быть его дочерними окнами. Что абсолютно никак не требуется по логике самого контрола — ни рисование, ни event processing не пострадают, если запчасти от контрола будут разнесены. А я, может быть, хочу линию вертикальную нарисовать между label и input. Упс, только наследоваться и сабкласситься.
Причем тут непосредственно вин-форм?
Кто мешает нарисовать эту линию без сабклассинга?
ВВ>>Я вот не знаю SWT или wxWidgets. Ну и как мне реагировать на всякие "вот в wxWidgets это сделано лучше". S>Как на повод повысить свою квалификацию. . Если тебе неинтересен вопрос "как должен быть устроен хороший GUI-framework", то не надо было поднимать эту тему в этом форуме. Если интересен — забей на устаревший отстой; смотри на лучшие достижения.
Я не поднимал тему "как должен быть устроен хороший GUI-framework". Помимо рассуждений о высоких вопросах стиля, людям еще работать надо. Причем на разных фреймворках.
ВВ>>Да ради бога, может и лучше. ВВ>>Собственно, если бы даже вин-формс были самым неудачным ГУИ-фреймворков (что абсолютно неправда на самом деле), это как бы не исключало того факта, что архитектурно они более правильны чем веб-формс. S>Знаешь, мне трудно сравнивать два отстоя на предмет большей или меньшей правильности. Их надо не сравнивать, а выкидывать на помойку.
Да, да, да, сотни приложений написаны на веб-форм, шарепоинт, продвигаемый всеми силами МС, написан на веб-форм, 99.99% ГУИ-приложений на дотнете написаны на вин-формах — чего мелочиться, давайте это все выкинем!
S>>>Я согласен. Только вот у веб-форм фундамент как раз хороший; гнилая там — только малозначительная надстройка. Ее можно безболезненно заменить, и построить на том же фундаменте совершенно другое решение. ВВ>>А какой фундамент у веб-форм? S>И в четвертый раз разжевываю: IHttpHandler/IHttpModule/BuildProvider. Вот основной фундамент. S>Дальше мы увидим еще N провайдеров, которые можно считать фундаментом, а можно — подвалом. Всё это сделано очень хорошо. ВВ>>Может, еще к архитектуре ИИС обратимся, и ее в плюсы веб-форм запишем? Всякие хендлеры — это практически тривиальная обвертка над ИЗАПИ, не более. S>Тривиальная? Ну-ну. Я бы вот так с налёту не смог написать аналог инфраструктуры ASP.NET. Ты вообще смотрел на классы ISAPI*? Или так, понты колотишь?
Здравствуйте, konsoletyper, Вы писали:
K>Ага, только колонки и можно расширять, и то весьма примитивно. А что если я захочу: группировку строк; строку с суммой/средним по строкам; объединённые ячейчки, грид, вложенный в ячейку; сложные заголовки? Всё это делается методом выкидывания DataGridView. K>Помню, даже для такой простой фичи, как автофильтры в заголовках столбцов, пришлось изрядно попотеть, и то вышло далеко не идеальное решение. Причём, хлопот доставил как сам DataGridView, так и кривая модель байндинга в WinForms.
Здравствуйте, konsoletyper, Вы писали:
K>В WPF эти трудозатраты будут сделаны один раз. Далее этот градусник можно будет засунуть куда угодно. В WindowsForms тебе придётся нарисовать градусник для контрола "градусник", градусник для кастомного типа столбцов в гриде, градусник внутри своего контрола TreeView, выпиленного целиком с нуля, ради того, чтобы он умел показывать градусник.
Правда что ли? Пиксели тогда не надо пилить, нарисуйте вектор.
Здравствуйте, Воронков Василий, Вы писали: ВВ>Причем тут непосредственно вин-форм? ВВ>Кто мешает нарисовать эту линию без сабклассинга?
Как кто??? В идеологии контрол == окно только контрол отвечает за рисование того, что в пределах его clip region.
ВВ>Я не поднимал тему "как должен быть устроен хороший GUI-framework". Помимо рассуждений о высоких вопросах стиля, людям еще работать надо. Причем на разных фреймворках.
А это какое отношение к теме имеет? И к какой?
ВВ>Да, да, да, сотни приложений написаны на веб-форм, шарепоинт, продвигаемый всеми силами МС, написан на веб-форм, 99.99% ГУИ-приложений на дотнете написаны на вин-формах — чего мелочиться, давайте это все выкинем!
Давайте. На Коболе написано значительно больше кода, чем на вин- и веб-формах вместе взятых. Это как-то влияет на наше желание и дальше разрабатывать на Коболе?
Вон МС в новой студии переписывает редактор на WPF. Видать, канонический RichEdit их не устраивает.
S>>Тривиальная? Ну-ну. Я бы вот так с налёту не смог написать аналог инфраструктуры ASP.NET. Ты вообще смотрел на классы ISAPI*? Или так, понты колотишь? ВВ>Архитектурно — да, тривиальная.
То есть всё же понты.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, konsoletyper, Вы писали:
K>>В WPF эти трудозатраты будут сделаны один раз. Далее этот градусник можно будет засунуть куда угодно. В WindowsForms тебе придётся нарисовать градусник для контрола "градусник", градусник для кастомного типа столбцов в гриде, градусник внутри своего контрола TreeView, выпиленного целиком с нуля, ради того, чтобы он умел показывать градусник.
ВВ>Правда что ли? Пиксели тогда не надо пилить, нарисуйте вектор.
Ну и зачем? Все равно вместо одного класса "мой клёвый редактор ктулхов" надо будет завести:
сам редактор
редактор для грида
....
Градусники:
градусник
градусник для грида
градусник для тривью
....
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Причем тут непосредственно вин-форм? ВВ>>Кто мешает нарисовать эту линию без сабклассинга? S>Как кто??? В идеологии контрол == окно только контрол отвечает за рисование того, что в пределах его clip region.
Ну и что? Все контролы находятся внутри родительского окна, вот в нем и рисуй.
Да и вообще какая-то надуманная проблема. Линия — это что? Часть "заголовка" контрола? Рисуй в заголовке. Это "разметка" самой формы, на которой контролы расположены? Рисуй по форме.
ВВ>>Я не поднимал тему "как должен быть устроен хороший GUI-framework". Помимо рассуждений о высоких вопросах стиля, людям еще работать надо. Причем на разных фреймворках. S>А это какое отношение к теме имеет? И к какой?
Прямое. Мы технологии обсуждаем разве не в разрезе их реального использования?
ВВ>>Да, да, да, сотни приложений написаны на веб-форм, шарепоинт, продвигаемый всеми силами МС, написан на веб-форм, 99.99% ГУИ-приложений на дотнете написаны на вин-формах — чего мелочиться, давайте это все выкинем! S>Давайте. На Коболе написано значительно больше кода, чем на вин- и веб-формах вместе взятых. Это как-то влияет на наше желание и дальше разрабатывать на Коболе?
Мне казалось, это вопрос практики, а не высокой теории и наших желаний. В разрезе желаний я бы вообще поговорил о чем-то другом, а не о всяких зловонных УИ-фреймворках.
S>Вон МС в новой студии переписывает редактор на WPF. Видать, канонический RichEdit их не устраивает.
Лучше бы они шарепоинт переделали.
Да, и RichEdit-то тут причем?
S>>>Тривиальная? Ну-ну. Я бы вот так с налёту не смог написать аналог инфраструктуры ASP.NET. Ты вообще смотрел на классы ISAPI*? Или так, понты колотишь? ВВ>>Архитектурно — да, тривиальная. S>То есть всё же понты.
Для того, чтобы написать ISAPI эстеншин еще в 6 вижуалке не надо было быть гуру. Там даже визард был специальный
И по "интерфейсу" получалось — те же яйца, вид сбоку.
Да, поэтому я и не хочу, считать, что прям IHttpHandler/IHttpModule — это прям вся соль асп-нета. Ибо нового в них ноль. И они ничего не дают такого, что не было бы доступно раньше. Просто еще одна удобная реализация. А билд-провайдеры позднее появились да и не везде нужны.
Здравствуйте, Aen Sidhe, Вы писали:
ВВ>>Здравствуйте, konsoletyper, Вы писали: K>>>В WPF эти трудозатраты будут сделаны один раз. Далее этот градусник можно будет засунуть куда угодно. В WindowsForms тебе придётся нарисовать градусник для контрола "градусник", градусник для кастомного типа столбцов в гриде, градусник внутри своего контрола TreeView, выпиленного целиком с нуля, ради того, чтобы он умел показывать градусник. ВВ>>Правда что ли? Пиксели тогда не надо пилить, нарисуйте вектор.
AS>Ну и зачем?
Для того, чтобы картинка была легко масштабируемой и вставлялась куда угодно. Ведь на это уйдет основное время разработки, нет?
AS>Все равно вместо одного класса "мой клёвый редактор ктулхов" надо будет завести:
А кто мешает написать один класс "мой клёвый редактор ктулхов"? Вин-формс конечно довольно примитивен по сравнению с WPF, но ведь это не значит, что мозг надо совсем отключать. Если логику можно сделать reusable, то ее можно сделать reusable независимо от того, какой УИ-фреймворк используется. Вин-формс в данном случае лишь обязует реализовать несколько разных "контрактов". Вот собственно и все. И вся трагедия.
AS>
AS>сам редактор AS>редактор для грида AS>.... AS>AS>Градусники: AS>
AS>градусник AS>градусник для грида AS>градусник для тривью AS>.... AS>
Универсальная модель расширения — это очень хорошо. Это упрощает расширение контролов. Но это никак не упрощает создание самого градусника, который в большинстве случаях все-таки нужен в единственной форме, а не в виде "мы интегрируемся во все контролы подряд".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А кто мешает написать один класс "мой клёвый редактор ктулхов"? Вин-формс конечно довольно примитивен по сравнению с WPF, но ведь это не значит, что мозг надо совсем отключать. Если логику можно сделать reusable, то ее можно сделать reusable независимо от того, какой УИ-фреймворк используется. Вин-формс в данном случае лишь обязует реализовать несколько разных "контрактов". Вот собственно и все. И вся трагедия.
Ну так я так и делаю. В результате у меня какая мысля возникла: а зачем делать какой-то невнятный helper-класс для отрисовки/обработки мыши/клавиатуры, а потом его ещё и пристёгивать к каждому конкретному случаю по-своему? А не проще ли сделать один на все случаи жизни MyControl, который содержал бы общий код для отрисовки и обработки ввода? А потом сделаю грид (наследующийся от MyControl, а не от Control), в котором в ячейках будут MyControl и TreeView (так же наследник MyControl), в котором так же в узлах дерева будут MyControl? Тогда из WindowsForms мне понадобятся только классы Control, на котором я буду отрисовывать корневой MyControl (очевидно — панелька со всем UT) и формочка, куда я буду класть этот Control. Мне даже этот тормоз GDI+ не понадобится, т.к. если я всё своими силами делаю, то и рендерер свой могу сделать, который будет основан на DirectX. Стоп! А зачем мне тратить n человеколет на такую непростую задачу, если я могу взять WPF?
Собственно, ты начал с того, что заявил, будто Web Forms — говно, Windows Forms — рулит. Я же, аналогично Синклеру, доказываю что говно и то и другое. Собственно, не то чтобы это говно во всех отношениях. Какие-то простенькие повседневные задачки они решают хорошо. В этом смысле Web Forms не проигрывает Windows Forms в плане удобства.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Интересно, а в WPF какой грид?
Никакого. Но чисто теоретически можно написать такой, чтобы в ячейках отображались произвольные контролы. И это будет работать хорошо. В Windows Forms если такое и сделаешь, то будет очень и очень плохо (в качестве упражнения предлагаю положить на формочку 400 кнопочек в виде таблицы 20x20 и посмотреть, что из этого выйдет).
Остальные вещи, да, достигаются за счёт правильного дизайна грида, а не за счёт WPF. Но! Ты как раз и говорил об убогости Web Form на примере того, что у тебя что-то не получилось расширить в стандартном DataGrid'е. Так что мешает для Web Forms взять нормальный грид?
Здравствуйте, konsoletyper, Вы писали:
K>Ну так я так и делаю. В результате у меня какая мысля возникла: а зачем делать какой-то невнятный helper-класс для отрисовки/обработки мыши/клавиатуры, а потом его ещё и пристёгивать к каждому конкретному случаю по-своему? А не проще ли сделать один на все случаи жизни MyControl, который содержал бы общий код для отрисовки и обработки ввода? А потом сделаю грид (наследующийся от MyControl, а не от Control),
Ну да, и получится еще что-то более уродливое, чем Control.
K>в котором в ячейках будут MyControl и TreeView (так же наследник MyControl), в котором так же в узлах дерева будут MyControl? Тогда из WindowsForms мне понадобятся только классы Control, на котором я буду отрисовывать корневой MyControl (очевидно — панелька со всем UT) и формочка, куда я буду класть этот Control.
А можно проще — пошел и купил готовый набор компонент. Только вот в отличие от веб-форм тут ты в итоге не упрешься в то, что сама концепция контролов и событий принципиально ущербно, мешает тебе работать и ее вообще надо выкинуть на хрен и напрямую с сообщениями работать.
K>Мне даже этот тормоз GDI+ не понадобится, т.к. если я всё своими силами делаю, то и рендерер свой могу сделать, который будет основан на DirectX.
Угу, "тормоз GDI+" просто летает по сравнению с софтварным рендерером у WPF.
K>Собственно, ты начал с того, что заявил, будто Web Forms — говно, Windows Forms — рулит.
Я не говорил, что "Windows Forms — рулит". Но Windows Forms — это говно в куда меньшей степени, чем Web Forms.
K>Я же, аналогично Синклеру, доказываю что говно и то и другое.
Неубедительно. Да и вместо того, чтобы что-то доказывать попробовал бы лучше лет пять поработать и с тем, и с другим. И посмотреть во что это реально выливается. Windows Forms хотя бы не мешает, в отличие от. Да и нормы построения вин и веб интерфейса несколько отличаются.
K>Собственно, не то чтобы это говно во всех отношениях. Какие-то простенькие повседневные задачки они решают хорошо. В этом смысле Web Forms не проигрывает Windows Forms в плане удобства.
Проигрывает. Потому что опраданий на построение веб-приложение по аналогии в вин-приложением нет никаких. Вообще.
"Простенькие повседневные задачи" можно и на ПХП решать. Там сейчас тоже библиотек хватает.
Здравствуйте, konsoletyper, Вы писали:
K>Никакого.
А я-то думал, ты мне про WPF Toolkit расскажешь, и начнется спор — говно этот тулкит или нет
Да, обломал
K>Но чисто теоретически можно написать такой
Теоретик блин
А чисто практически можно пойти и купить грид у Инфрагистика.
Причем покупали грид у Инфрагистика, когда писали на Актив-Икс.
Покупали грид у Инфрагистика, когда писали на вин-формс.
И будут покупать грид у Инфрагистика для WPF.
K>, чтобы в ячейках отображались произвольные контролы.
Не вижу в этом проблемы даже со стандартным ГридВью (который, кстати, очень неплох для стандартного контрола, а ждать какого-то супер-грида от МС — это утопия). Другим компаниям тоже кушать хочется.
K>И это будет работать хорошо. В Windows Forms если такое и сделаешь, то будет очень и очень плохо (в качестве упражнения предлагаю положить на формочку 400 кнопочек в виде таблицы 20x20 и посмотреть, что из этого выйдет).
Если ты таким образом тулбары делаешь, то неудивительно, что тебе вин-формс не нравится.
Вообще надо бы отделять представление данных, для которого никаких новых окошек делать не надо, и редактирование данных.
K>Остальные вещи, да, достигаются за счёт правильного дизайна грида, а не за счёт WPF. Но! Ты как раз и говорил об убогости Web Form на примере того, что у тебя что-то не получилось расширить в стандартном DataGrid'е. Так что мешает для Web Forms взять нормальный грид?
Пример грида показывает не убогость грида, а убогость контрола на вебе вообще. Контролы на вебе не нужны. Нужен полноценный метаязык. Вин != Веб. Задачи разные. Попробуйте подумайть над этим не только в ключе "что бы тут возразить".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
ВВ>>>Здравствуйте, konsoletyper, Вы писали: K>>>>В WPF эти трудозатраты будут сделаны один раз. Далее этот градусник можно будет засунуть куда угодно. В WindowsForms тебе придётся нарисовать градусник для контрола "градусник", градусник для кастомного типа столбцов в гриде, градусник внутри своего контрола TreeView, выпиленного целиком с нуля, ради того, чтобы он умел показывать градусник. ВВ>>>Правда что ли? Пиксели тогда не надо пилить, нарисуйте вектор.
AS>>Ну и зачем?
ВВ>Для того, чтобы картинка была легко масштабируемой и вставлялась куда угодно. Ведь на это уйдет основное время разработки, нет?
Масштабируемость контролов при зуме — конечно красиво, но далеко не всегда необходима. Или я неправильно понял?
AS>>Все равно вместо одного класса "мой клёвый редактор ктулхов" надо будет завести:
ВВ>А кто мешает написать один класс "мой клёвый редактор ктулхов"? Вин-формс конечно довольно примитивен по сравнению с WPF, но ведь это не значит, что мозг надо совсем отключать. Если логику можно сделать reusable, то ее можно сделать reusable независимо от того, какой УИ-фреймворк используется. Вин-формс в данном случае лишь обязует реализовать несколько разных "контрактов". Вот собственно и все. И вся трагедия.
Речь как раз об этом. Зачем делать сто тысяч разных хелпер-контролов? Какая ж это реюзабельность? Реюзабельность (в моём понимании) — "взял, заюзал", а не "взял, допилил напильником, отполировал нулёвкой, заюзал".
Посмотрите, кстати, любую библиотеку с контролами коммерческую. 99% используют только Control. И выстраивают всю иерархию заново. Наверно неспроста.
ВВ>Универсальная модель расширения — это очень хорошо. Это упрощает расширение контролов. Но это никак не упрощает создание самого градусника, который в большинстве случаях все-таки нужен в единственной форме, а не в виде "мы интегрируемся во все контролы подряд".
В WPF, насколько мне известно, мы один раз рисуем градусник. Вроде бы это не слишком сложно. А потом вставляем куда надо. Будь то грид или форма, или текстбокс. Вставляем без тысяч хелпер классов.
Здравствуйте, Aen Sidhe, Вы писали:
ВВ>>Для того, чтобы картинка была легко масштабируемой и вставлялась куда угодно. Ведь на это уйдет основное время разработки, нет? AS>Масштабируемость контролов при зуме — конечно красиво, но далеко не всегда необходима. Или я неправильно понял?
Не знаю, правильно или нет, но для того, чтобы отрисовать градусник и в ячейке, и в "крупноформатном" варианте, наверное, нужна масштабируемость.
AS>>>Все равно вместо одного класса "мой клёвый редактор ктулхов" надо будет завести:
ВВ>>А кто мешает написать один класс "мой клёвый редактор ктулхов"? Вин-формс конечно довольно примитивен по сравнению с WPF, но ведь это не значит, что мозг надо совсем отключать. Если логику можно сделать reusable, то ее можно сделать reusable независимо от того, какой УИ-фреймворк используется. Вин-формс в данном случае лишь обязует реализовать несколько разных "контрактов". Вот собственно и все. И вся трагедия. AS>Речь как раз об этом. Зачем делать сто тысяч разных хелпер-контролов? Какая ж это реюзабельность? Реюзабельность (в моём понимании) — "взял, заюзал", а не "взял, допилил напильником, отполировал нулёвкой, заюзал".
Сто тысяч — это легкое преувеличение
Ну да, несколько — не хелперов, а именно формальных реализаций вин-формых "контрактов" — сделать придется. И да, я не вижу в этом трагедии, хотя без них было бы конечно лучше.
И "внутренней красоты" при таком подходе бесспорно не хватает. Но обычно не до "красоты".
AS>Посмотрите, кстати, любую библиотеку с контролами коммерческую. 99% используют только Control. И выстраивают всю иерархию заново. Наверно неспроста.
Действительно, неспроста они, видимо, Control используют, несмотря на всю "уродливость" его контракта.
ВВ>>Универсальная модель расширения — это очень хорошо. Это упрощает расширение контролов. Но это никак не упрощает создание самого градусника, который в большинстве случаях все-таки нужен в единственной форме, а не в виде "мы интегрируемся во все контролы подряд".
AS>В WPF, насколько мне известно, мы один раз рисуем градусник.
В вин-формс тоже один раз рисуем.
О чем спор вообще? О том, что WPF "круче", чем вин-формс? Я разве это отрицал где-то?
Речь про "градусник" вообще зашла в разрезе того, что ГДИ+ — отстой, и в нем надо все по пикселям выпилить. А вот в WPF нарисовать все куда проще.
Да не так уж чтобы проще. Если мы именно про "рисование" говорим. И "выпиливать по пикселям" ничего в ГДИ+ не надо — это очередной перл из области, что "в вин-формс для расширения функционала надо всегда наследоваться". Возможно, в WPF это и удобнее. Но речь не об этом.
Я вообще не хочу спорить на тему вин-формс версус WPF, ибо это будет действительно глупо К тому же у меня промышленного опыта использования WPF, а именно он мне и интересен, банальная практика, а не "внутренняя красота" и прочая. Так что тут вообще непонятно что с чем сравнивать.
Да, WPF предлагает принципиально другой подход, да он совершеннее в плане архитектуры и многие задачи в нем решаются проще. Да, постепенно все перейдут с вин-формс на WPF — но пока этот процесс еще далек от завершения. И работать надо с тем, что есть.
AS>Вроде бы это не слишком сложно. А потом вставляем куда надо. Будь то грид или форма, или текстбокс. Вставляем без тысяч хелпер классов.
Здравствуйте, Воронков Василий, Вы писали:
K>>Но чисто теоретически можно написать такой
ВВ>А чисто практически можно пойти и купить грид у Инфрагистика. ВВ>Причем покупали грид у Инфрагистика, когда писали на Актив-Икс. ВВ>Покупали грид у Инфрагистика, когда писали на вин-формс. ВВ>И будут покупать грид у Инфрагистика для WPF. ВВ>
А чисто практически никто и не говорил. Чисто практически есть и Инфрагистик, и ДевЭкспресс и так далее. Я говорю про чисто теоретическую возможность написать грид, у которого в ячейках находились бы произвольные контролы. Так вот для Windows Forms этого сделать нельзя. Для WPF — можно (и сделано)
K>>, чтобы в ячейках отображались произвольные контролы.
ВВ>Не вижу в этом проблемы даже со стандартным ГридВью (который, кстати, очень неплох для стандартного контрола, а ждать какого-то супер-грида от МС — это утопия). Другим компаниям тоже кушать хочется.
Нет-нет. Если ты в каждой ячейке покажешь по контролу, то начнутся жуткие тормоза. Заметь, я говорю про контролы, находящиеся внутри ячеек всегда, а не только в момент редактирования. Кстати, а что там насчёт контролов, встраиваемых в заголовки?
K>>И это будет работать хорошо. В Windows Forms если такое и сделаешь, то будет очень и очень плохо (в качестве упражнения предлагаю положить на формочку 400 кнопочек в виде таблицы 20x20 и посмотреть, что из этого выйдет).
ВВ> Если ты таким образом тулбары делаешь, то неудивительно, что тебе вин-формс не нравится.
Вот уже хватит, надоел этот снисходительный тон. Ты не думал, что у человека, с которым ты общаешься, может быть опыт не меньший, чем у тебя?
ВВ>Вообще надо бы отделять представление данных, для которого никаких новых окошек делать не надо, и редактирование данных.
Здравствуйте, Воронков Василий, Вы писали:
K>>Ну так я так и делаю. В результате у меня какая мысля возникла: а зачем делать какой-то невнятный helper-класс для отрисовки/обработки мыши/клавиатуры, а потом его ещё и пристёгивать к каждому конкретному случаю по-своему? А не проще ли сделать один на все случаи жизни MyControl, который содержал бы общий код для отрисовки и обработки ввода? А потом сделаю грид (наследующийся от MyControl, а не от Control),
ВВ>Ну да, и получится еще что-то более уродливое, чем Control.
В большинстве случаев — да. Если же руки прямые и написание подобного фреймворка ставится как самоцель профессионалами, то получается нечто хорошее.
K>>в котором в ячейках будут MyControl и TreeView (так же наследник MyControl), в котором так же в узлах дерева будут MyControl? Тогда из WindowsForms мне понадобятся только классы Control, на котором я буду отрисовывать корневой MyControl (очевидно — панелька со всем UT) и формочка, куда я буду класть этот Control.
ВВ>А можно проще — пошел и купил готовый набор компонент. Только вот в отличие от веб-форм тут ты в итоге не упрешься в то, что сама концепция контролов и событий принципиально ущербно, мешает тебе работать и ее вообще надо выкинуть на хрен и напрямую с сообщениями работать.
Сама концепция контролов в WindowsForms, в том виде, в котором она есть, не позволяет сделать описанного, даже если закупить супер-мега контролов. Ты вообще читаешь, что тебе пишут?
K>>Мне даже этот тормоз GDI+ не понадобится, т.к. если я всё своими силами делаю, то и рендерер свой могу сделать, который будет основан на DirectX.
ВВ>Угу, "тормоз GDI+" просто летает по сравнению с софтварным рендерером у WPF.
Никто не говорил про софтварный рендерер. Нле я сказал про это?
K>>Я же, аналогично Синклеру, доказываю что говно и то и другое.
ВВ>Неубедительно. Да и вместо того, чтобы что-то доказывать попробовал бы лучше лет пять поработать и с тем, и с другим. И посмотреть во что это реально выливается. Windows Forms хотя бы не мешает, в отличие от. Да и нормы построения вин и веб интерфейса несколько отличаются.
А что, из моих слов следует, что я вообще ни с тем ни с другим не работал и месяца? Не говоря уж о других технологиях?
K>>Собственно, не то чтобы это говно во всех отношениях. Какие-то простенькие повседневные задачки они решают хорошо. В этом смысле Web Forms не проигрывает Windows Forms в плане удобства.
ВВ>Проигрывает. Потому что опраданий на построение веб-приложение по аналогии в вин-приложением нет никаких. Вообще. ВВ>"Простенькие повседневные задачи" можно и на ПХП решать. Там сейчас тоже библиотек хватает.
Твоя аргументация? Всё, что я видел до этого "вот тут неудобно, тут неудобно, приходится переписывать на XSLT". Когда я использую Windows Forms у меня тоже возникает чёс в руках выкинуть всё нафиг и рендерить через GDI+ самому. Чего именно в аналогии не так?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
ВВ>>>Для того, чтобы картинка была легко масштабируемой и вставлялась куда угодно. Ведь на это уйдет основное время разработки, нет? AS>>Масштабируемость контролов при зуме — конечно красиво, но далеко не всегда необходима. Или я неправильно понял?
ВВ>Не знаю, правильно или нет, но для того, чтобы отрисовать градусник и в ячейке, и в "крупноформатном" варианте, наверное, нужна масштабируемость.
А, ну да. Протупил, бывает.
AS>>>>Все равно вместо одного класса "мой клёвый редактор ктулхов" надо будет завести:
ВВ>>>А кто мешает написать один класс "мой клёвый редактор ктулхов"? Вин-формс конечно довольно примитивен по сравнению с WPF, но ведь это не значит, что мозг надо совсем отключать. Если логику можно сделать reusable, то ее можно сделать reusable независимо от того, какой УИ-фреймворк используется. Вин-формс в данном случае лишь обязует реализовать несколько разных "контрактов". Вот собственно и все. И вся трагедия. AS>>Речь как раз об этом. Зачем делать сто тысяч разных хелпер-контролов? Какая ж это реюзабельность? Реюзабельность (в моём понимании) — "взял, заюзал", а не "взял, допилил напильником, отполировал нулёвкой, заюзал".
ВВ>Сто тысяч — это легкое преувеличение
На каждый чих (читай, новый композитный контрол) — новый хелпер.
ВВ>Ну да, несколько — не хелперов, а именно формальных реализаций вин-формых "контрактов" — сделать придется. И да, я не вижу в этом трагедии, хотя без них было бы конечно лучше.
Трагедии нет. Есть кривизна
ВВ>И "внутренней красоты" при таком подходе бесспорно не хватает. Но обычно не до "красоты".
Кому как.
AS>>Посмотрите, кстати, любую библиотеку с контролами коммерческую. 99% используют только Control. И выстраивают всю иерархию заново. Наверно неспроста.
ВВ>Действительно, неспроста они, видимо, Control используют, несмотря на всю "уродливость" его контракта.
Наверно это потому, что его нельзя не использовать в винформах, не находите? А не от его замечательной архитектуры. И смотреть надо на то, что заменены даже такие простые контролы как текстбокс или комбобокс (дерьмо то ещё, кстати)
Или ты хочешь сказать, что нужно непременно признать, что мышление человека происходит непосредственно в терминах языка?
Если ты таким образом тулбары делаешь, то неудивительно, что тебе вин-формс не нравится.