Комментарии 181
Минусанул тебе карму, ибо достали уже такие «знатоки».
Согласен. Досих пор использую Delphi 7 которую купил лет еще 15 назад (как то даже диск на глаза попадался :) ). Не спорю это не основная среда разработки, но если надо реально за 30 минут накидать виндовое приложение и которое будет работать практически везде и кроме переноса exe-файла ничего не требует (BDE не использую :) ), то это идеальна вещь. Некоторые проги написанные 10 лет назад все еще работают у людей и они их меня не хотят.
И чего душой кривить, вот 30 числа нужно было срочно написать конвертор для больших файлов для отправки в ЕГАИС… реально 20 минут и готово.
И чего душой кривить, вот 30 числа нужно было срочно написать конвертор для больших файлов для отправки в ЕГАИС… реально 20 минут и готово.
Нам, дельфистам, некогда курить и пить пиво — работы много. И если честно, не видно внятных альтернатив для решения конкретного ряда задач.
К примеру: система финансово-управленческого учёта специального назначения, Windows native (требование спорное, но оно есть), ничего лишнего, максимальная эргономика с защитой от дурака и зловреда, минимальное время реакции на изменяющиеся требования бизнеса, минимальные требования к инфраструктурному обеспечению (типа ничего, кроме sql сервера).
Предложите альтернативу, я рассмотрю. Честно-честно. Давно хочу альтернативу.
Qt+cpp;
Это в лучшем случае шило на мыло. Ну т.е. если вы знаете C++, и вам нужна среда быстрой разработки толстых, но нативных приложений, то Qt для вас вполне годится. Но мигрировать на неё с Delphi, это просто головная боль, куча времени на поиск новых граблей, и ноль преимуществ в итоге.
Вы кормите мудаков из Эмбракадеро? Ну кто-то же должен кормить мудаков...)
Извини, но ты мудак ;)
На остальное отвечать тебе не вижу смысла.
Поразительно то, что к каждой статье про Delphi найдется такой мудак, не способный пройти мимо. Благо теперь стали минусовать их.
Я тоже чего-то не понял, почему компилятор Delphi, по вашему мнению, не развивается? И вообще возникло сомнения, — а знаете ли вы что представляют собой современная версия Delphi?
Вы кормите мудаков из Эмбракадеро?
Так, чисто для справки: коммерческая лицензия на Qt стоит порядка $150/месяц.
На Qt будет дольше, с БД работать если и что-то кастомизировать, нужно написать модельки свои, делегатики. В Дельфи это займёт 5 минут мышекликаньем. RAD конечно лучше, чем в Дельфи никто не сделал.
Шутка не должна выглядеть так, было неприятно получить «это» в качестве первого комментария вместо обоснованной критики под своей статьей, тебя заминусовали за это, и не только дельфисты.
А оправдываться что в случае лазаруса ты бы не оставил здесь свой «полезный» комментарий не стоит.
А оправдываться что в случае лазаруса ты бы не оставил здесь свой «полезный» комментарий не стоит.
Взгляд со стороны — это тупая шутка.
- Lazarus, к сожалению, не является полноценной альтернативой Delphi. Для добавления нового компонента в среду разработки необходима пересборка самой среды разработки, что отнимает немало времени и ломает то самое преимущество "склепал за несколько минут работающее приложение".
- QT не подходит по другой причине: у него намного меньше автоматизации при написании кода. Все это мелочи, конечно, но разработку замедляет существенно, что и определяет все то же конкурентное преимущество Delphi — "быстро склепать приложение".
Единственным реальным конкурентом Delphi (в старом понимании сего бренда, сейчас это дело объединили под общим названием) я назвал бы CBuilder, который использует тот же способ быстрой разработки приложений. Но на C++ RAD технология (если правильно помню ее наименование) ложится из-за особенностей языка гораздо хуже.
С теплотой вспоминаю эти среды разработки.
Часто встречались на форумах претензии к качеству компилятора у билдера особенно на работу с ссылками. Но по скорости разработки, я в 90х писал и на Дельфи и на Билдере, разницы в принципе никакой не было, на билдере всё было так же быстро и приятно.
Жаль, что не сделали среду под Линукс нормальную. (Kylix) так и не взлетел, компилятор вроде не исправили, после перехода на ядро 2.4.18 — помнится, поменяли формат ELF файлов, а Борланду было уже не до него.
Часто встречались на форумах претензии к качеству компилятора у билдера особенно на работу с ссылками. Но по скорости разработки, я в 90х писал и на Дельфи и на Билдере, разницы в принципе никакой не было, на билдере всё было так же быстро и приятно.
Жаль, что не сделали среду под Линукс нормальную. (Kylix) так и не взлетел, компилятор вроде не исправили, после перехода на ядро 2.4.18 — помнится, поменяли формат ELF файлов, а Борланду было уже не до него.
Ещё была Watcom Optima. Кто не помнит, Watcom — это фирма которая делала оптимизирующий компилятор Watcom C а затем и C++. Многие игры, работавшие под DOS4GW компилировались Watcom-ом. В Википедии об этом продукте только одна строчка:
Так вот, Optima++ выглядела примерно как первый 32-битный C++Builder, с различными удобными фичами. Причём поскольку она не несла груз совместимости с Win16 в неё не было VCL-подобного монстра, всё было проще, компактней и поддерживались все Win32-контролы и все их свойства. В общем, «Жаль что она умерла».
Watcom was acquired by Powersoft in 1994, and Powersoft merged with Sybase in 1995.[2] In May 2000, Sybase spun off their mobile and embedded computing division into its own company, Sybase iAnywhere (formerly iAnywhere Solutions Inc.). Sybase tried to re-target the Watcom compiler into a visual RAD tool, Optima++, but in 2003, because the product competed directly with the Sybase offering PowerBuilder, the product was discontinued.
Так вот, Optima++ выглядела примерно как первый 32-битный C++Builder, с различными удобными фичами. Причём поскольку она не несла груз совместимости с Win16 в неё не было VCL-подобного монстра, всё было проще, компактней и поддерживались все Win32-контролы и все их свойства. В общем, «Жаль что она умерла».
Имел возможность познакомиться с этим продуктом. Неплохая штука. Но рядом с CBuilder и Delphi оно и рядом не стояло в плане быстроты разработки.
В RAD от Borland была достигнута самая высокая степень автоматизации создания приложения. И VCL — закономерная плата за это, иначе было просто невозможно столь просто связывать элементы управления друг с другом, создавать на их базе новые и простым образом подключать получившееся как элемент конструктора.
Что-то отдаленно близкое по идеологии разработки приложений, пожалуй, в те старые добрые времена было только у IBM с их Visual Age C++, хотя и он не был столь удобен, как продукция от Borland.
Даже современным конкурентам до Delphi и CBuilder далеко.
Как правило у конкурентов все ограничивается "рисованием интерфейса" и "созданием основных функций для реакции на события". А вот связать визуальные и не визуальные компоненты парой кликов мышки — уже нет. Да и у тех, кто продвинулся чуть дальше, все равно не то.
Delphi и прочие тулзы быстрого связывания GUI с событиями и логикой поощряют смешение GUI с моделью и проводят к антипаттерну «GUI Trap». Поэтому отделение GUI от модели это хорошо и правильно. А delphi-йский подход «всё в кучу» ужасен. Чтобы нормально отделить GUI от модели в delphi надо затратить не меньше, а то и больше усилий чем в средах где это изначально отдельные вещи.
Так Delphi в общем-то не для больших долго сопровождаемых проектов.
У них в теории другая ниша: в течении короткого отрезка времени (максимум неделя) сваять достаточно простое работающее приложение. Т.е. для быстрого создания одноразовых (а если вдруг сразу получится хорошо, то и постоянно применяемых, но это уже скорее случайность) инструментов, быстрого макетирования "на коленке".
И именно для этой ниши инструмент подходит идеально, намного обходя конкурентов.
При проектировании более серьезных проектов все эти возможности уже дейчствительно теряют актуальность, и особых преимуществ в разработке не дают. Но описанная выше ниша реально существует и требует соответствующего инструмента, который на данный момент представлен продуктами-наследниками Delphi и CBuilder (как они там сейчас называются, "RAD Studio"?).
Бред какой, 15 лет проектам, проекты сложные, ответственные, миллион+ строк кода. Недавно частично перенесены на линукс под лазарусом.
И их таких много, судя по конференциям. Не говорите о том, о чем понятия не имеете.
И их таких много, судя по конференциям. Не говорите о том, о чем понятия не имеете.
Я как раз имею понятие, в том числе о разработке сложных и простых проектов под Delphi, поскольку сам и тем, и другим непосредственно занимался.
Возможно, я не вполне по русски выразился, или вы читали через слово, но я совсем не отрицаю возможности использования Delphi для больших сложных проектов.
Просто баланс использования разных возможностей Delphi несколько меняется. И в результате конкуренты Delphi становятся уже не такими "бесконечно отстающими", а очень даже близкими. И выбор в пользу Delphi становится не таким уж и однозначным, как в случае простых приложений.
По моему опыту при создании простых приложений очень полезна возможность все сделать в несколько кликов мышью, в том числе и невизуальную часть. А при создании серьезных приложений это уже отходит на второй план (разве только при макетировании в начале разработки), а основное внимание уже уделяется собственно коду и его правке "руками". И большое количество связей невизуальных компонент, "спрятанных" в дизайн формы, уже начинает в некоторой степени мешать и раздражать, а потому потихоньку частично "переезжает" непосредственно в код.
Даже если ускорение будет не на порядок (т.е. в 10 раз), а в два раза — то и это хороший результат. В проектах же, где форм много (вижу часто на форуме обсуждают 200-300 форм), преимущества быстрой визуальной разработки остаются. Замечу, что визуальная разработка касается не только интерфейса. В невизуальные компоненты обернуто большое количество кода, сложно найти какую-то нишу в программировании, для которой отсутствуют соответствующие компоненты. А если такая ниша и есть — то есть повод сделать недостающие компоненты :)
Вообще, кто-то всерьёз в 21-м веке предлагает делать меню вот так:
???? И ставит мне минусы, когда я предлагаю RAD альтернативы? Удивительные люди :)
Можно также вспомнить отличную переносимость кода вверх. Делфи, может, несколько консервативен, зато переносимость кода у него отличная. А это — один из больших плюсов как раз на долгоиграющих больших проектах. Насколько я знаю — этим могут похвастаться далеко не все языки.
Вообще, кто-то всерьёз в 21-м веке предлагает делать меню вот так:
???? И ставит мне минусы, когда я предлагаю RAD альтернативы? Удивительные люди :)
Можно также вспомнить отличную переносимость кода вверх. Делфи, может, несколько консервативен, зато переносимость кода у него отличная. А это — один из больших плюсов как раз на долгоиграющих больших проектах. Насколько я знаю — этим могут похвастаться далеко не все языки.
Разработка чего-то вроде приведенного примера автоматизируется не только в Delphi, а потому не является преимуществом Delphi,
А вот возможность мышкой быстро набросать неочевидные связи между визуальным и невизуальным (то самое конкурентное преимущество) при сопровождении большого проекта часто превращается в серьезную проблему (т.е. в совсем не преимущество), поскольку эти связи не всегда просто отслеживаются (в силу своей необязательности и неочевидности).
Есть, конечно, вещи достаточно простые и понятные вроде таймера на форме.
А вот когда, например, в изобилии появляются разнообразные компоненты для доступа к БД, связанные с различными визуальными компонентами, то при превышении некоторой сложности проекта становится "весело". Оно, конечно, красиво и на первый взгляд понятно выглядит, но спрятанные связи...
а потому не является преимуществом Delphi
Согласен на такую формулировку: является преимуществом не только Delphi.
Стоит смотреть не только наличие механизма визуального проектирования, но и на количество и качество компонент для Делфи и для других языков.
Пример с другого форума, сравнивали компоненты TRichEdit для разных языков:
Delphi:
C++
то при превышении некоторой сложности проекта становится «весело».
У нас не было описанных проблем, и я ни разу не видел жалобы на это на форумах, возможно, просто повезло, конечно.
Схемы данных не помогут?
И каким именно образом схемы данных могут помочь быстро понять, с каким именно TDatabase связаны различные TQuery? А таких связей у компонента может быть очень много.
И каким именно образом схемы данных могут помочь быстро понять, с каким именно TDatabase связаны различные TQuery?
Если опустить тот момент, что задумываться о связи между TQuery и TDatabase вам придется скорее всего только один раз, в момент первичной настройки TQuery, то в Delphi для этого был другой инструмент, назывался Object TreeView или что-то в этом роде. В любом случае, VCL спроектирована таким образом, что связи между компонентами в подавляющем большинстве случаев иерархические, а не «многие ко многим», и хорошо визуализируются и анализируются. Я в своё время участвовал во многих достаточно крупных проектах на Delphi, с мегабайтами текстов и сотнями форм. Своих проблем хватало, но чего-чего, а проблем со сложными неочевидными связями между компонентами не было никогда.
при сопровождении большого проекта часто превращается в серьезную проблему
Это больше вопрос соблюдения архитектурных стандартов, нежели недостатков среды разработки. Можно подумать, с помощью делегатов и свойств в C# есть какая-то сложность сделать жуткий спагетти-код.
Вопрос в необходимости отказа в больших проектах от использования главного конкурентного преимущества Delphi, без которого он становится таким же, как остальные IDE с редактором форм. И тогда начинают сказываться другие вопросы вроде крайней падучести многих версий Delphi, особенно обостряющейся на как раз больших проектах.
У меня и 7-ка, и 2010, и XE6 работают стабильно. Несколько проектов около миллиона строк. Падений минимум, особенно в более свежих версиях. Да, было несколько нестабильных версии — так никто не заставляет на них работать.
Не знаю — откуда у вас появляется такая глобальная проблема со связями. У меня таких проблем не было ни разу.
У себя, что бы связи к базам долго не искать, расставляю компоненты на дата-модулях. Вот, например, один из модулей, каждая транзакция под своим коннектом. Всё связанное — снизу. Просто, удобно и всё видно:
Не знаю — откуда у вас появляется такая глобальная проблема со связями. У меня таких проблем не было ни разу.
У себя, что бы связи к базам долго не искать, расставляю компоненты на дата-модулях. Вот, например, один из модулей, каждая транзакция под своим коннектом. Всё связанное — снизу. Просто, удобно и всё видно:
Добавьте к этому многопоточность, connection-пулы, вложенные транзакции и увидите что всё это надо будет переписывать. Кстати вижу тут Indy — сталкивался с этой библиотекой. Чтобы заставить Indy работать многопоточно надо также приложить немало усилий, по сравнению с которыми возможность увидеть его иконку на форме — ничто.
Чтобы заставить Indy работать многопоточно надо также приложить немало усилий, по сравнению с которыми возможность увидеть его иконку на форме — ничто.
Я лет десять назад писал HTTP-сервер для клиент-банка на Indy. Многопоточный, с пулом коннектов, с шифрованием и т.д… Поэтому хотелось бы, чтобы вы уточнили, какие там усилия были нужны. У меня, насколько я помню, от библиотеки не потребовалось ничего — там всё прекрасно работало из коробки. Только класс-прокладку от TIdHTTPServer к датамодулю WebBroker надо было подправить.
Конкретно в Indy нотификация реализуется с большим оверхедом.
Проблема Indy в концепции 1 соединение = 1 поток, это ограничивает кол-во одновременно обрабатываемых соединений сверху. Зависит, конечно, от размера стека, выделяемого по умолчанию, а так порой уже на ~~1300 соединениях оно упирается в потолок VA на 32 разрядах.
Да ну, ~1300 параллельных соединений, это, минуточку, уже счёт на сотни миллионов запросов в сутки на один сервер. Там узким местом уж точно не Indy будет.
Это смотря, что за сервер, что за задача. Если это сервер приложений — да. Вот у меня была задача — сделать нестандартное проксирование http и ws, с балансировкой к тому же. Есть сервер, за ним 5 серверов приложений, на каждом по 1000 соединений (индёвые в свою очередь). Каждое соедиение — keep alive канал тонкого клиента, т.е. объем данных невелик — события интерфейса в одну сторону, отрисовки patch'ами в другую — без проблем может прокачиваться одним сервером. А вот создать эти 5000 каналов уже не так просто.
В итоге приходится искать решение через хитрые комбинации nginx с другими инструментами с отказом от части требований.
В итоге приходится искать решение через хитрые комбинации nginx с другими инструментами с отказом от части требований.
это шот рабочего проекта, если что. пулы, инди. всё работает. 100-200 потоков обрабатывается сервисом, для связи с гуем сервиса используется CmdServer, 40 команд гоняется туда-сюда, этот же сервер является веб сервером, только шот от другого модуля.
IBQuery1? JvThread1? Серьезно? У Вас несколько проектов в миллион строк с такими вот IBTransaction10? Когда вижу такое, хочется автору руки поотрывать. Неужели сложно потратить две секунды и назвать элемент по-нормальному? Неужели в западло относиться к себе и другим программистом с уважением? Я сейчас в похожем проекте копаюсь — хрен разберешь, что и зачем — приходится трассировать в уме и догадываться, что автор имел ввиду, вместо того, чтобы просто читать.
Мне бы такое выкладывать было стыдно.
Мне бы такое выкладывать было стыдно.
del
Можно также вспомнить отличную переносимость кода вверх.
О да!
var
Bounds: TRect;
Width: Integer;
...
with Bounds do
begin
Width := Right - Left;
...
Упс, в новой версии у record появились свойства, в том числе и Width у TRect…
То, что за использование with стоит бить по рукам — другой вопрос.
Поэтому with не рекомендуют использовать, или хотя бы не давать переменным распространенные имена.
Поэтому with не рекомендуют использовать
Что никак не мешает им быть в унаследованном коде.
не давать переменным распространенные имена.
Это не серьёзно. Имена должны быть удобными и понятными.
в данном случае Width не является удобным и понятным, в реальном коде переменная будет иметь составное имя — «чегототамWidth».
на практике проблема с with возникает когда указывают несколько объектов — with a, b do, и в b появляется то к чему обращаешься в a.
другие случаи это криворукость программиста
на практике проблема с with возникает когда указывают несколько объектов — with a, b do, и в b появляется то к чему обращаешься в a.
другие случаи это криворукость программиста
Апологеты вообще счастливы от блокнота…
Если же вас зацепила первая фраза, то это просто реальная характеристика инструмента, который можно использовать в самых разных целях.
Если для быстрого создания простых приложений Delphi подходит идеально и на порядок лучше других, в то время как в других областях он хотя и очень даже подходит, но уже совсем не лучший, то логично предположить, что он все-таки предназначен именно для для быстрого создания простых приложений, а не для больших проектов.
Он предназначен для быстрой разработки приложений. А какого у вас будут размера проекты — зависит от вас. Ни QT ни VC ни C# ни Javа не делают код сам по себе лучше. Качество кода зависит от разработчика, как и архитектура. преимущество Delphi в том, что позволяет писать как на чистом API, так и в RAD (rapid application development)стиле.
И при добавлении каждого нового модуля его можно сразу писать серьезно прорабатывая архитектуру, а можно визуально набросать необоходимый функционал, вернуться к основному функционалу, а затем постепеннно прорработать этот модуль. это сильно сокращает общие сроки разработки проекта.
И при добавлении каждого нового модуля его можно сразу писать серьезно прорабатывая архитектуру, а можно визуально набросать необоходимый функционал, вернуться к основному функционалу, а затем постепеннно прорработать этот модуль. это сильно сокращает общие сроки разработки проекта.
У меня есть работы которым уже 25-27 лет…
это как? Delphi появился в 1995 )
Возможно проекты еще из TurboPascal
Мало кто помнит, но было что-то типа Pascal For Windows или что-то такое. Без визуальных плюшек.
Turbo Pascal for Windows. Продавался (если это слово можно применять к софту, который мы видели в СССР) и как отдельный продукт, и в составе пакета Borland Pascal 7.0. Не совсем без визуальных, там был вполне себе визуальный редактор ресурсов, в котором рисовались формы и диалоги.
BPW — Borland Pascal for Windows. Входила в комплект Borland Pascal вместе с Turbo Pascal
Что будете делать, если нужно будет сделать приложение для mac os или мобильных устройств? Я вижу только альтернативу в веб приложениях js/scalajs/clojurescript + react/angular 2 + electron/cordova. Везде работает, одна кодовая база.
Delphi, как и большинство других современных средств разработки, давно позволяет делать приложения и для мобильных устройств, и для macOS. Надо иметь в виду, что у Delphi немного иная ниша, чем у веб-приложений. Delphi чаще всего используют для разработки бизнес-приложений, где чаще всего предполагается какая-либо активная работа с БД. «Фишка» Delphi, которая с ней была изначально, это удобные биндинги к базам данных и data-aware контролы, особенно гриды. В веб-платформах, к сожалению, ничего столь мощного нет в силу ограничений, накладываемых броузерами (ближе всего подобрался devExpress, но там другие нюансы есть). Поэтому потребность делать мобильные клиенты на Delphi не так часто бывает востребованной. Да и, честно говоря, далеко не всегда выгоднее иметь одну кодовую базу и слои адаптации под разные платформы, чем иметь несколько различных клиентов, каждый из которых оптимизирован под свою платформу.
Делфи сейчас работает на всех основных платформах — Win32/64, iOS, Android, MacOS, серверный линукс почти сделали. Собранный код по производительности может и проигрывает плюсам в некоторых случаях, но большинство частей библиотек хорошо оптимизированы ассемблером.
У Лазаруса список поддерживаемых платформ вообще огромен. При том, что он бесплатный, и последние сборки, например, отсюда: https://www.getlazarus.org вполне пригодны для работы. Есть биндинги Qt и Gtk, под виндой и линуксом. Так что для того, что бы работать с Qt совсем не обязательно переходить на плюсы.
JS, который мы тоже используем, сильно ограничен рамками браузера. Некоторые банальные вещи — например — копирование в буфер в нём сделать просто нельзя. Многие вещи браузеро-зависимые. То есть — получается не просто платформы, а куча браузеров на множестве платформ. Мы активно используем HMLT5, многопоточную обработку, WebGL. У разных браузеров на разных платформах свои особенности. Вместо написания функциональности приходится постоянно заниматься оптимизацией под браузеры.
У Лазаруса список поддерживаемых платформ вообще огромен. При том, что он бесплатный, и последние сборки, например, отсюда: https://www.getlazarus.org вполне пригодны для работы. Есть биндинги Qt и Gtk, под виндой и линуксом. Так что для того, что бы работать с Qt совсем не обязательно переходить на плюсы.
JS, который мы тоже используем, сильно ограничен рамками браузера. Некоторые банальные вещи — например — копирование в буфер в нём сделать просто нельзя. Многие вещи браузеро-зависимые. То есть — получается не просто платформы, а куча браузеров на множестве платформ. Мы активно используем HMLT5, многопоточную обработку, WebGL. У разных браузеров на разных платформах свои особенности. Вместо написания функциональности приходится постоянно заниматься оптимизацией под браузеры.
http://www.unigui.com
Платная, да. По цене смартфона. Есть и бесплатные варианты, например http://www.morfik.com
Есть backend-фреймворки — https://github.com/silvioprog/brookframework
Платная, да. По цене смартфона. Есть и бесплатные варианты, например http://www.morfik.com
Есть backend-фреймворки — https://github.com/silvioprog/brookframework
Возможно будет интересно:
Web Front End Framework (on Delphi)
Web Front End Framework (on Delphi)
система финансово-управленческого учёта специального назначения
ничего лишнего, максимальная эргономика с защитой от дурака и зловреда, минимальное время реакции на изменяющиеся требования бизнеса, минимальные требования к инфраструктурному обеспечению (типа ничего, кроме sql сервера)
Как вариант платформа 1С 8.3.х. (про цену лицензий в требованиях ничего не было :)). Но если система большая то цена лицензий в стоимости системы занимает от силы 1% ну и Delphi тоже не бесплатная.
По остальным показателям именно в «финансово-управленческом учёте» 1С вполне способна составить конкуренцию Delphi.
А если нужно и «минимальное время реакции на изменяющиеся требования бизнеса» то delphi сильно отстает от 1С.
А если нужно и «минимальное время реакции на изменяющиеся требования бизнеса» то delphi сильно отстает от 1СГде?!!!
Главная проблема с 1С — то, что она живёт своей жизнью, развивается и обновляется исходя из собственных интересов. Фактически, с какого-то момента придётся выбирать — или фиксировать их версию, или минимизировать своё вмешательство. И что будет через несколько лет такой жизни? Тут нету полного контроля и владения. Что и зачем там происходит внутри — тема для отдельной платной консультации. Куча лишних сущностей, нам не нужных, при том, что наверняка нет отдельных немаловажных кусочков.
Это как тот халат — перламутровые пуговицы на него перешить можно, но галоши не наденешь без боли. А бизнес хочет галоши и шляпу.
Короче, вы упустили слова: «специального назначения» (не универсальная, не общего назначения), «ничего лишнего». Из рыночного ПО — это, наверное, поле для ERP систем, до которых 1С ценой не доросла. Вот только реальное внедрение и сопровождение ERP — очень затратная вещь в реальности.
Не буду спорить по поводу лишних сущностей и отдельных кусочков. По старой памяти в Delphi всего этого не меньше а с учетом проблем в сторонних компонентах и с учетом того что зачастую сторонние компоненты поставляются с закрытыми исходниками и контроля над ними не намного больше.
В целом же платформа содержит все что не обходимо:
1. Работа с почтой, фтп, WEB сервисы (как сервер так и клиент) HTTP сервисы (аналогично), поле HTML документа позволяет встраивать HTML в разрабатываемые решения.
2. Мощная система контроля доступа на уровне строк RLS
3. Ведение журналов на уровне системы
4. Мощная система отчетов которую в т.ч. могут настраивать и пользователи СКД
5. Работа с COM
6. Поддержка всего более менее используемого торгового оборудования (Сканеры ШК, терминалы смарт карт, фискальные регистраторы, кассовые аппараты).
Это далеко не полный список. Плюс многие разработки уже есть в типовых системах и так же доступна БСП в которой накоплен опыт огромной компании и которая доступна при разработке своих решений.
«Вот только реальное внедрение и сопровождение ERP — очень затратная вещь в реальности.»
Вы хотите сказать что написать с 0 систему уровня ERP и затем внедрить ее на предприятии намного дешевле? Сколько времени вам потребуется на написание подобной системы?
В целом же при прочих равных на 1С можно гораздо быстрее и гораздо дешевле написать для бизнеса практически все что можно написать на Delphi.
Притом вы сразу получаете WEB клиент + в нагрузку возможность создать клиентов для Android/IOS
В качестве примера, сколько денег и времени у вас уйдет на реализацию:
https://www.youtube.com/watch?v=DgPuF_WTyB8
В 1С это будет доступно по подписке ИТС (которая в общем то есть почти всегда).
А бизнесу это нужно еще вчера.
В целом же платформа содержит все что не обходимо:
1. Работа с почтой, фтп, WEB сервисы (как сервер так и клиент) HTTP сервисы (аналогично), поле HTML документа позволяет встраивать HTML в разрабатываемые решения.
2. Мощная система контроля доступа на уровне строк RLS
3. Ведение журналов на уровне системы
4. Мощная система отчетов которую в т.ч. могут настраивать и пользователи СКД
5. Работа с COM
6. Поддержка всего более менее используемого торгового оборудования (Сканеры ШК, терминалы смарт карт, фискальные регистраторы, кассовые аппараты).
Это далеко не полный список. Плюс многие разработки уже есть в типовых системах и так же доступна БСП в которой накоплен опыт огромной компании и которая доступна при разработке своих решений.
«Вот только реальное внедрение и сопровождение ERP — очень затратная вещь в реальности.»
Вы хотите сказать что написать с 0 систему уровня ERP и затем внедрить ее на предприятии намного дешевле? Сколько времени вам потребуется на написание подобной системы?
В целом же при прочих равных на 1С можно гораздо быстрее и гораздо дешевле написать для бизнеса практически все что можно написать на Delphi.
Притом вы сразу получаете WEB клиент + в нагрузку возможность создать клиентов для Android/IOS
В качестве примера, сколько денег и времени у вас уйдет на реализацию:
https://www.youtube.com/watch?v=DgPuF_WTyB8
В 1С это будет доступно по подписке ИТС (которая в общем то есть почти всегда).
А бизнесу это нужно еще вчера.
«Вот только реальное внедрение и сопровождение ERP — очень затратная вещь в реальности.»
Вы хотите сказать что написать с 0 систему уровня ERP и затем внедрить ее на предприятии намного дешевле? Сколько времени вам потребуется на написание подобной системы?
Лет 13-14 и можно не останавливаться… Её не надо писать — она есть. И вопрос в том, целесообразен ли переход на 1с, если организационных проблем возникнет — море, а существующая система в полном порядке, развивается, дорабатывается и свои задачи выполняет?
Я не говорю, что 1с — это неправильно. Кому как. Есть много правильных решений, и наше — одно из них. И если вернуться чуть пораньше, речь шла не о выборе разрабатывать / покупать, а «Несчастные, вы пишете на Дельфи?!!! Есть же куча более модных языков!» — «Да, мы пишем на Дельфи, и нам кайфно! Мы счастливые, правда!». Честно, не знаю никого, кто наслаждается программированием под 1С. Не говорю, что их нет, но правда — не знаю.
Видео про 54-ФЗ глянул, честно говоря, мельком — уж очень медленно барышня вещает. Кассу с передачей данных коллега прикрутил со вторника по утро пятницы, и самое сложное было, судя с моей стороны наблюдателя, это экономия бумаги (торгуем оптом, чеки получаются многометровые). Вот и все затраты на более, чем 10 филиалов. Никаких настроек на местах, никаких семинаров по 3500 рублей за билет. Купят несколько десятков касс, подключат, будут работать. У бизнеса это уже есть, и даже не вчера.
по нумерованным пунктам — у нас это тоже есть. Есть автоматизация склада, есть интеграция с системами мобильной торговли, есть электронный документооборот с поставщиками… Много чего есть. И зачем платить за 1С? Из любви к революциям? Может, у нас меньше перламутровых пуговиц и размеренно вещающих видеобарышень, но всё, что нужно, есть сейчас и будет потом.
Сразу скажу, что у меня два рабочих инструмента 1С и Delphi. И оба инструмента знаю на экспертном уровне. Так вот…
Есть гигантская масса учетных задач где 1С нет равных по скорости разработки. Стоимость лицензии, по сравнению экономией на разработке и стоимостью владения, ничтожна.
Есть гигантская масса других задач, которые решить с помощью 1С никак нельзя. Тут вотчина Delphi и еже с ними.
В спорах по лицензиям 1С не нужно забывать и такой аспект как единовременность этих выплат. Лицензия покупается один раз и потом на этой машине можно использовать столько баз (конфигураций) – сколько душе угодно. Так часто и поступают: Берут «бухгалтерию», а потом еще с десяток внутренних систем внедряют.
Можно долго спорить что круче, но если 1С-ник понятия не имеющий про SQL, утечки памяти и прочие «интересности», может в мгновение ока, буквально на коленке, наклепать мини учетную систему — это дорогого стоит. И только за одно это 1С можно уважать.
Я бы лучше и не сформулировал. Они ведь на основе чего-то строят свои планы по развитию платформы. Или типа художник так видит….
Есть гигантская масса учетных задач где 1С нет равных по скорости разработки. Стоимость лицензии, по сравнению экономией на разработке и стоимостью владения, ничтожна.
Есть гигантская масса других задач, которые решить с помощью 1С никак нельзя. Тут вотчина Delphi и еже с ними.
В спорах по лицензиям 1С не нужно забывать и такой аспект как единовременность этих выплат. Лицензия покупается один раз и потом на этой машине можно использовать столько баз (конфигураций) – сколько душе угодно. Так часто и поступают: Берут «бухгалтерию», а потом еще с десяток внутренних систем внедряют.
Можно долго спорить что круче, но если 1С-ник понятия не имеющий про SQL, утечки памяти и прочие «интересности», может в мгновение ока, буквально на коленке, наклепать мини учетную систему — это дорогого стоит. И только за одно это 1С можно уважать.
Главная проблема с 1С — то, что она живёт своей жизнью
Я бы лучше и не сформулировал. Они ведь на основе чего-то строят свои планы по развитию платформы. Или типа художник так видит….
а таки ваше гецэцэ умеет вицээль? А поддерживать старое легаси писанное и переписанное на дельфях как на гэцеце? Ах да, Reference counting и DCOM+ из коробочки, выньте да положте, пожалуйста…
Спасибо. Будем пробовать.
В свое время пользовался Delphi разных версий 3, 4, 5, 6. Большую часть делал интерфейсы, кастомные контролы и псевдо 3D на cos и sin. Были времена, приятно вспомнить.
Плюсую WM_ERASEBKGND.
Изучать надо WinAPI, тогда и проблем не будет.
Работаю с OWL/VCL более 20 лет. Про «проблему мерцания» слышу в первый раз.
Изучать надо WinAPI, тогда и проблем не будет.
Работаю с OWL/VCL более 20 лет. Про «проблему мерцания» слышу в первый раз.
но вы форсируете «папу» «напечататься» (WM_PRINTCLIENT), а это может иметь побочные эффекты. Лет адцать назад я встречал контролы, которые не давали «печататься» — чтобы нельзя было сделать, скажем, слепок с защищенной пдфки, которую контрол демонстрирует.
Как я уже писал, класс показал свою надежную работу :)
Но для таких «кривоватых» контролов я сделал виртуальный метод procedure DrawBackground(DC: HDC); virtual;, в котором для обхода проблем подобных компонентов можно переопределить отрисовку фона.
Кроме того компонент имеет множество настроек буферизации.
Спасибо! Интересно.
Про мерцание уже забыл по двум причинам: не использую большое количество контролов на форме и, наоборот, использую дискретные видео-карты и хорошим 2D-рендерингом.
К сожалению начиная с Windows Vista, GDI практически перестало использовать 2д ускорение, и к сожалению проблема мерцания никуда не ушла, да о чем говорить — многие стандартные Windows приложения мерцают.
Блин, вы о чем?
Что за мерцание?
Пример такого стандартного Windows приложения и как это самое мерцание воспроизвести?
Как я уже писал: «Откройте стандартный «диспетчер устройств» и попробуйте изменять размер окна, оцените мерцание.».
Windows 10
Открыл Device Manager — ничего не мерцает, как я ни меняю размер окна.
С какой частотой и как быстро его надо менять?
Открыл Device Manager — ничего не мерцает, как я ни меняю размер окна.
С какой частотой и как быстро его надо менять?
Важно чтобы было не было отключено «Отображать содержимое окна при перетаскивании».
Можно еще открыть «Управление компьютером» и полистать там вкладки.
Можно еще открыть «Управление компьютером» и полистать там вкладки.
Ну предположим, что я совсем идиот, и флаг "отображать содержимое" у меня был отключен.
Проблема в том, что он был включён и поведение не воспроизводилось.
Аналогично с вкладками компьютера.
Вы можете уточнить свою конфигурацию, на которой вы это воспроизводите?
Win7, открываю диспетчер задач и начинаю его ресайзить туда-сюда: мерцают верхние вкладки.
Последняя стабильная Windows 10. При изменении размера влево вправа мерцает. Не каждое изменение, но мерцает. Попробуйте секунд 5 изменять и увидите
Воспроизвелось.
Действительно надо достаточно долго его туда/сюда дергать.
Но я не уверен, что подобное требует фикса :)
Действительно надо достаточно долго его туда/сюда дергать.
Но я не уверен, что подобное требует фикса :)
Это не проявляется так явно в простом интерфейсе, без активной кастомной отрисовки, если же интерфейс сложный, наполнен кастомными контролами, то от мерцания вытекают глаза.
ЕМНИП, году в 1996/1997 на VB4.0 решалась подобная задача путем отрисовки «всей» формы в буфер и только после этого вывода ее.
Наследовать компоненты не требовалось, более того этот механизм работал и с вообще чужими компонентами, которые и знать не знали что мы боремся с мерцанием.
Наследовать компоненты не требовалось, более того этот механизм работал и с вообще чужими компонентами, которые и знать не знали что мы боремся с мерцанием.
Как вы интересно боролись если не знали о мерцании?
Блин, вы о чем?
Что за мерцание?
Как вы интересно боролись если не знали о мерцании?
Легко боролись.
Точно так же как друг на курсовой боролся с ним же при рендере самодельной ртс.
Но вот где-то с начала 2000-х как-то не доводилось встречать настолько криворукие офисные приложения где прямо необходимо было с этим бороться.
Отсюда и удивление, что кто-то сейчас умудряется это мерцание встречать…
И что удивительно создавать его в своих приложениях, чтобы
от мерцания вытекают глаза.
Легко боролись.
Точно так же как друг на курсовой боролся с ним же при рендере самодельной ртс.
Я к тому, что странно бороться с мерцанием, не зная что это:
Блин, вы о чем?
Что за мерцание?
И что удивительно создавать его в своих приложениях, чтобы
Ну майкрософт создает как-то же?
решалась подобная задача путем отрисовки «всей» формы в буфер и только после этого вывода ее.
К слову в Win32 невозможно все окно забуферизировать нормально.
Я думаю вы просто «не в теме», проблема есть, и простых способов «из коробки» нет
Я к тому, что странно бороться с мерцанием, не зная что это:
Я к тому, что не у рукожопов эта проблема в офисных приложениях отсутствует как класс настолько давно, что упоминание вызывает удивление.
И решения из коробки не было и в 90-х
В том же vb4 приложении использовались вызовы winapi функций из gdi32 библиотеки.
Какие конкретно уже не помню. В памяти остались лишь ключевые слова getDC, HWND
Ну майкрософт создает как-то же?
Угу, ровно там и так, что надо очень постараться, чтобы его заметить и воспроизвести.
Это сильно отличается от ваших приложений от которых, по вашим словам «вытекают глаза».
Я к тому, что не у рукожопов эта проблема в офисных приложениях отсутствует как класс настолько давно, что упоминание вызывает удивление.
Ну раз я, все отблагодарившие меня, люди использующие в своих проектах данное решение «рукожопы», то я не намерен продолжать дискуссию.
Минусанул.
Это ваши личные комплексы.
Миллионы леммингов не могут ошибаться…
Миллионы леммингов не могут ошибаться…
Этим вы показываете свое невежество и некомпетентность.
Естественно.
Ведь вы один из тех миллионов.
И вы, конечно же, не ошибаетесь
Ведь вы один из тех миллионов.
И вы, конечно же, не ошибаетесь
Откуда вы только беретесь?
Успокойся, если не понимаешь о чем речь — промолчи, не надо засирать комментарии.
Успокойся, если не понимаешь о чем речь — промолчи, не надо засирать комментарии.
Оттуда откуда и такие же «программисты» вроде вас юноша…
Сначала пишут такие программы
Потом героически преодолевают трудности…
Сначала пишут такие программы
Потом героически преодолевают трудности…
О, я смотрю вы заглянули мне в профиль?
Переход на личности — еще один показатель вашей полной некомпетентности.
Переход на личности — еще один показатель вашей полной некомпетентности.
В чём проблема этой картинки?
перегруженность интерфейса вестимо.
Хотя это не худший из образцов, просто первый попавшийся
Хотя это не худший из образцов, просто первый попавшийся
Не совсем понимаю, как Вы по одной картинке определили перегруженность.
Возможно, в данном случае такой вид был оправдан.
Возможно, в данном случае такой вид был оправдан.
Это психология.
Объем человеческого внимания ограничен.
Оправдан или нет это отдельная тема
Объем человеческого внимания ограничен.
Оправдан или нет это отдельная тема
Под этим лозунгом делают новомодные «упрощенные приложения для домохозяек», в которых чтобы добраться до нужного функционала надо пробираться через тонны менюшек, или функционал вообще выпилен.
Учитесь проектировать интерфейсы.
ЕМНИП у того же SAP в каких-то продуктах доступ к экрану интерфейса любого уровня вложенности можно было получить в три нажатия клавиши
ЕМНИП у того же SAP в каких-то продуктах доступ к экрану интерфейса любого уровня вложенности можно было получить в три нажатия клавиши
Ну покажите пример хороших интерфейсов спроектированных вами, а то у вас в профиле ссылки на домены неоплаченные ;)
Не всегда есть резон упрощать интерфейс, ломая при этом удобство использования.
Не всегда есть резон упрощать интерфейс, ломая при этом удобство использования.
Во-первых, профилю примерно треть вашей жизни уже.
Соответственно редактировался он года 3-4 назад
Во-вторых, офисным ПО не занимаюсь уже примерно половину вашей жизни.
В-третьих, ваше «не всегда» это детский лепет.
Поскольку удобство использования напрямую зависит от навыков человека и в том числе его внимания.
Если этого самого внимания не хватает, то и скорость и удобство использования будут отрицательными.
Соответственно редактировался он года 3-4 назад
Во-вторых, офисным ПО не занимаюсь уже примерно половину вашей жизни.
В-третьих, ваше «не всегда» это детский лепет.
Поскольку удобство использования напрямую зависит от навыков человека и в том числе его внимания.
Если этого самого внимания не хватает, то и скорость и удобство использования будут отрицательными.
Во-первых, профилю примерно треть вашей жизни уже.
Во-первых нет ничего тупее апеллирования возрастом оппонента.
Соответственно редактировался он года 3-4 назад
Тем не менее это показатель.
Во-вторых, офисным ПО не занимаюсь уже примерно половину вашей жизни.
Во-вторых, если вы не занимаетесь уже давно разработкой ПО, ваши знания могли устареть.
А очередное упоминание возраста не красит вас.
В-третьих, ваше «не всегда» это детский лепет.
Поскольку удобство использования напрямую зависит от навыков человека и в том числе его внимания.
Если этого самого внимания не хватает, то и скорость и удобство использования будут отрицательными.
В-третьих, вы вообще не привели никаких логичных доводов, кроме упоминания возраста.
Я, как пользователь, чувствую неудобство от «интерфейсов для домохозяек», и я рад когда применяется инженерный подход, пусть и не всегда красивый, но при этом удобный и функциональный.
Предлагаю закончить этот флейм.
Во-вторых, если вы не занимаетесь уже давно разработкой ПО, ваши знания могли устареть.
Я тупых не люблю категорически.
Упоминание vb4 должно было явно вам показать когда это было. Более того никакой отсылки к современному апи не было.
Вы решили вернуться к этому вопросу повторно.
В связи с этим у меня есть вопрос — вы тупой?
Тем не менее это показатель.
Показатель это то, что указанные домены в свое время держали нагрузку в 2-2.5 млн уникальных посетителей в сутки
А это вам статистика рунета сейчас
http://www.liveinternet.ru/rating/ru/
Для понимания.
Я, как пользователь, чувствую неудобство от «интерфейсов для домохозяек», и я рад когда применяется инженерный подход, пусть и не всегда красивый, но при этом удобный и функциональный.
Вы путаете инженерный подход и тяп-ляп перегруженный интерфейс по факту.
В результате инженерного подхода может родиться как тысячекнопочный так и двухкнопочный интерфейс.
Вы путаете инженерный подход и тяп-ляп перегруженный интерфейс по факту.
В результате инженерного подхода может родиться как тысячекнопочный так и двухкнопочный интерфейс.
Вот именно, при инженерном подходе может выйти интерфейс с кучей контролов, который для кого-то будет выглядеть перегруженным, но для человека пользующегося этой программой он будет очень удобным.
Показатель это то, что указанные домены в свое время держали нагрузку в 2-2.5 млн уникальных посетителей в сутки
А это вам статистика рунета сейчас
http://www.liveinternet.ru/rating/ru/
Вы можете написать что угодно задним числом, почему я должен в это верить?
А писал я о том, как можно обвинять кого-то в криворукости, тупости и т.д. когда вы не удосужились из профиля ссылки нерабочие потереть за столько лет?
Я тупых не люблю категорически.
Упоминание vb4 должно было явно вам показать когда это было. Более того никакой отсылки к современному апи не было.
Вы решили вернуться к этому вопросу повторно.
В связи с этим у меня есть вопрос — вы тупой?
Я долго пытался не поддаваться на провокации, но вы усердно добивались своего, и вы добились!
Вы — критин.
Вот именно, при инженерном подходе может выйти интерфейс с кучей контролов, который для кого-то будет выглядеть перегруженным, но для человека пользующегося этой программой он будет очень удобным.
Это не инженерный подход.
Рекомендую сходить в интернет и почитать об этом.
Вы можете написать что угодно задним числом, почему я должен в это верить?
А писал я о том, как можно обвинять кого-то в криворукости, тупости и т.д. когда вы не удосужились из профиля ссылки нерабочие потереть за столько лет?
Не обязаны. И мне собственно говоря насрать верите вы или нет.
Презентационная роль профиля мне сейчас не требуется. Соответственно зачем мне его исправлять или тем более писать что-то вроде «лучший контрол....»? :-D
P.S.
Вы — критин.
крЕтин
Вы, однако, очень вежливый.
Я тупых не люблю категорически.
Получается вы сами себя недолюбливаете?
Не получается.
3 человека из 1000 с таким же или более высоким интеллектом немного примиряют меня с моими недостатками.
3 человека из 1000 с таким же или более высоким интеллектом немного примиряют меня с моими недостатками.
У истинного интеллектуала хватит интеллекта чтобы не писать о своем интеллекте в комментариях.
Не знаю о ваших недостатках, но у вас явно комплексы связанные с уровнем IQ
Не знаю о ваших недостатках, но у вас явно комплексы связанные с уровнем IQ
Показатель это то, что указанные домены в свое время держали нагрузку в 2-2.5 млн уникальных посетителей в сутки
И мы типа джентльмены должны верить друг другу на слово?
А нагрузка разве в уникальных посетителях измеряется? правда?
тогда и мне есть чем похвастать:
Мой домашний компьютер легко справляется с обработкой 15-80 тысяч запросов (статика) в секунду. Получается если в среднем уникальный посетитель генерирует 100 хитов, то мой домашний компьютер будет «держать» 25-30 млн. уникальных посетителей в сутки.
Понятно что мой пример (как и ваш) — это метрики сферических коней в вакууме. Но все же получается, что ваши домены справлялись с нагрузкой на порядок меньшей чем моя домашняя (не самая навороченная) машина.
Таким образом вытекает самый главный вопрос:
Как же вы умудрились добиться столь низких показателей производительности для вашего сферического коня в вакууме?
А теперь верну вам ваше же выражение — вопрос (цитата):
В связи с этим у меня есть вопрос — вы тупой?
и закончу вашим же выражением
Я тупых не люблю категорически
тут согласен. Вы мне явно не нравитесь…
А нагрузка разве в уникальных посетителях измеряется? правда?
тогда и мне есть чем похвастать:
Ну вот когда вашу статику захотят посмотреть в таких объемах, тогда и поговорим о разнице в нагрузке между статикой и полнотекстовым поиском.
А до тех пор не обезьяничайте, пытаясь подражать мне
Ну вот когда вашу статику захотят посмотреть в таких объемах, тогда и поговорим о разнице в нагрузке между статикой и полнотекстовым поиском.
Так статистику вашего полнотекстового поиска никто и не видел. Это лишь ваши слова — то есть пшик.
А до тех пор не обезьяничайте, пытаясь подражать мне
Обезьянничая подражать вам? Вы себя считаете обезьяной, коль подражая вам обезьянничают?
Но позвольте! Вы себе явно льстите, я вам не вовсе и подражал.Много чести для обезьяны…
То есть, если я внезапно найду в архивах статистику, то вы начнёте бить челом и извиняться? :-D
Ну ок, а мне-то это зачем?
Ну раз для вас слишком много чести…
То, гражданин обезьяна, самоликвидируйтесь из обсуждения непонятно чего.
Ну ок, а мне-то это зачем?
Вы себе явно льстите, я вам не вовсе и подражал.Много чести для обезьяны…
Ну раз для вас слишком много чести…
То, гражданин обезьяна, самоликвидируйтесь из обсуждения непонятно чего.
А иногда ещё и время надо экономить этому пользователю и не путать его в десятке окон с двумя параметрами.
Я бы в качестве ещё одного примера привёл окно проводника. Особенно момент уменьшения до размера, когда пропадает риббон
странно что вообще проблема с мерцанием еще есть, всмысле, ведь ее решили на уровне винды — «композитор» с висты работает с двойной буферизацией в принципе.
«композитор» решает проблему композиции только окон верхнего уровня.
и? как раз для этого он держит буфер для каждого окна и туда пишутся все команды отрисовки а потом результат выводится, мерцание возможно только если дать команду заставляющую «композитор»отрисовать окно на экране.
да и вообще, прежде чем написать, я проверил — с выключенными темами мерцает с включенными нет.
да и вообще, прежде чем написать, я проверил — с выключенными темами мерцает с включенными нет.
Как я уже писал: «Откройте стандартный «диспетчер устройств» и попробуйте изменять размер окна, оцените мерцание.».
Возможно у вас быстрая машина и вы не успеваете заметить мерцание, или приложение на котором вы проверяете буферизирует отрисовку.
Возможно у вас быстрая машина и вы не успеваете заметить мерцание, или приложение на котором вы проверяете буферизирует отрисовку.
т.е. по хорошему, двойную буферизацию надо отключать когда программу по RDP запустили а с висты еще когда темы включены, как-то так.
А если моргать синхронно с мерцанием, то мерцание вообще не увидеть =)
Поднадоели исходники С# и C++ в функциональном стиле, как приятно видеть старый добрый Паскаль, только из-за этого прочёл всю статью, да и в общем-то актуальная тема, но не хватает гифок. Ещё бы с Russian AI CUP какой-нибудь Дельфист выложил мемуары, вообще было бы шикарное начало года.
Очень хотелось почитать какие-нить свежие статьи по free-pascal или delphi, но устранением мерцания в VCL я занимался лет 18-20 назад. Неужели ничего нового с тех пор не возникло?
Проблема мерцания и прозрачности все еще актуальна, по причине актуальности VCL, который базируется на довольно консервативном WinApi.
Новое есть — если про VCL, то теперь есть поддержка юникода, скинов.
Появился новый интерфейсный фреймворк — FMX, а с ним и поддержка MacOS, Android, iOS.
В следующем релизе будет серверный Linux.
Ну и кончено же в языке много изменений произошло.
Новое есть — если про VCL, то теперь есть поддержка юникода, скинов.
Появился новый интерфейсный фреймворк — FMX, а с ним и поддержка MacOS, Android, iOS.
В следующем релизе будет серверный Linux.
Ну и кончено же в языке много изменений произошло.
Если позволите, небольшое замечание по имени переменной
Используйте Childs или Children (а еще лучше глагол: BufferChilds). Слова Childrens не существует, ибо Children — уже множественное число.
Класс имеет свойство BufferedChildrens
Используйте Childs или Children (а еще лучше глагол: BufferChilds). Слова Childrens не существует, ибо Children — уже множественное число.
Да, есть ошибка, знаю, но исправить «легко и просто» нельзя к сожалению, это сломает много кода(не моего).
Но я знаю как можно в течении времени исправить, добавив правильный «двойник» свойства, скрыть в дизайнере неправильное свойство через ToolsApi и т.д., при этом из dfm будет считываться неверное свойство, а записываться будет верное свойство. Если возможно будет исправить не сломав совместимость, то будет исправлено.
Но я знаю как можно в течении времени исправить, добавив правильный «двойник» свойства, скрыть в дизайнере неправильное свойство через ToolsApi и т.д., при этом из dfm будет считываться неверное свойство, а записываться будет верное свойство. Если возможно будет исправить не сломав совместимость, то будет исправлено.
Небольшое отступление. В MS видимо в курсе проблемы, но для приложений, использующих классический API (в т.ч. это большинство системных) видимо нормального решения нет. Именно по-этому для классов ListView и TreeView они добавили встроенную двойную буферизацию, которая работает явно лучше, предложенной в VCL.
См. TVS_EX_DOUBLEBUFFER и LVS_EX_DOUBLEBUFFER.
См. TVS_EX_DOUBLEBUFFER и LVS_EX_DOUBLEBUFFER.
Согласен, у меня в EsVclComponents есть модуль специальный, который включает «родную» буферизацию для TListView: ES.VclFix.pas
Его достаточно подключить в файле с формой :)
Его достаточно подключить в файле с формой :)
{$ifdef VER210UP} {$REGION 'BACKUP'}
(*
// Main magic located here:
procedure TESCustomControl.PaintWindow(DC: HDC);
var
BufferDC, TempDC: HDC;
BufferBitMap: HBITMAP;
UpdateRect: TRect;
SaveViewport: TPoint;
Region: HRGN;
beginЗачем вам система контроля версий, если вы продолжаете хранить полуразложившиеся трупы в комментариях?
(я не автор поста) Иногда удаленный код удобно оставлять в комментариях, чтобы видеть его происхождение через blame/diff. Иначе отследить, что тут когда-то давно был какой-то код, довольно сложно
Ну потому что если код может вызвать вопросы «откуда это произошло», ответ лучше оставить рядом с кодом, а не заставлять каждого вопрошающего заниматься прикладной археологией в системе контроля версий.
Ответ уже написали сверху.
На сколько я помню всё можно было буферизировать кроме richedit эта редиска плевать хотела на dc который ей передают и вместо текста получалась дырка от бублика. Вы смогли это победить?
Иногда использую вариант такой
нет ни мерцания, и задержка на обращение к компоненту снижается по времени раз в 10, придумал такое «методом тыка». Может кому-то пригодится тоже.
memo1.visible.false
// много изменений в сожержимом
memo1.visible.true
нет ни мерцания, и задержка на обращение к компоненту снижается по времени раз в 10, придумал такое «методом тыка». Может кому-то пригодится тоже.
Настоятельно не рекомендую пользоваться таким способом, вам «повезло» что он работает, но нет никаких гарантий что не сломается или не даст необычные глюки.
Используйте:
Используйте:
Memo1.Lines.BeginUpdate;
try
// изменения
finally
Memo1.Lines.EndUpdate;
end;
Специально попробовал ваш способ (думал магия есть).
Мерцания пропало (как и ожидалось), но теперь получился просто исчезающий и появляющийся компонент.
По мне так лучше будет мерцание, чем моргание всем компонентом ))
Мерцания пропало (как и ожидалось), но теперь получился просто исчезающий и появляющийся компонент.
По мне так лучше будет мерцание, чем моргание всем компонентом ))
Спасибо за статью! Интересный подход.
Ого! Вот это зачет!
Помню, сколько я часов провел на форумах, применяя всякие уловки против мерцания… Честно признаюсь, я в то время так и не нашел годного решения. Потому данная статья вызвала лично мне приятную ностальгию, а автору — реальное уважение.
Я когда-то около трех лет работал с VCL, правда на CBuilder. Задачей было организовать автоматизацию с красивым интерфейсом быстрыми темпами в одном банке. На то время лучшего решения чем Delphi5/CBuilder5 (кому что нравилось) попросту не было. Вот, столько лет прошло, а наши программы до сих пор нормально и успешно там работают без всякого саппорта.
Теперь же, работая чуть в другой сфере, отойдя от оконных приложений, мне лично, особенно когда надо «нафигачить что-то под винду с окнами побырику» кроме RADStudio я ничего не хочу знать, он меня устраивает всем. На CBuilder, к примеру, я пишу редактор уровней для своего движочка. Правда, чтобы избавиться от мерцания основного поля, я полностью отказался от TCanvas в его классическом применении, рендерю в него прямо OpenGL контекст.
Помню, сколько я часов провел на форумах, применяя всякие уловки против мерцания… Честно признаюсь, я в то время так и не нашел годного решения. Потому данная статья вызвала лично мне приятную ностальгию, а автору — реальное уважение.
Я когда-то около трех лет работал с VCL, правда на CBuilder. Задачей было организовать автоматизацию с красивым интерфейсом быстрыми темпами в одном банке. На то время лучшего решения чем Delphi5/CBuilder5 (кому что нравилось) попросту не было. Вот, столько лет прошло, а наши программы до сих пор нормально и успешно там работают без всякого саппорта.
Теперь же, работая чуть в другой сфере, отойдя от оконных приложений, мне лично, особенно когда надо «нафигачить что-то под винду с окнами побырику» кроме RADStudio я ничего не хочу знать, он меня устраивает всем. На CBuilder, к примеру, я пишу редактор уровней для своего движочка. Правда, чтобы избавиться от мерцания основного поля, я полностью отказался от TCanvas в его классическом применении, рендерю в него прямо OpenGL контекст.
Спасибо за статью. У меня были свои методы борьбы с таким, но как правило с собственными контролами. Стандартные почти всегда работали вполне приемлемо и так. А сейчас я вообще в делфи ушел в геймдев, поэтому совсем неактуально стало. Но всё-равно любопытно.
Спасибо за статью, часто борюсь с тем или иным мерцанием в своих компонентах. Какие только пути не изобретал.
Спасибо за статью.
Присоединяюсь, спасибо за статью и компоненты.
Уже использую в проекте, обнаружил непонятное поведение TEsLayout при использовании тем.
Пишу в личку.
Уже использую в проекте, обнаружил непонятное поведение TEsLayout при использовании тем.
Пишу в личку.
Почему то все статьи об Delphi вызывают кучу негатива и много холивара. Во всяком случае Delphi просто инструмент, который позволяет быстро реализовать приложение, и не важно будет это Delphi, Visual Studio или XCode — все равно в итоге это будет бинарник. Я думаю, что каждый пользуется тем, чем ему удобнее и он лучше ориентируется в языке и среде.
А разгадка проста — людям завидно, что вместо Делфи им приходится работать на том, что ранее выбрали 'эффективные менеджеры' за них в качестве рабочего инструмента:
При этом кто-то продолжает спокойно, в своё удовольствие, работать с полюбившимся инструментом, не смотря на то, что его активно постоянно поливали и поливают грязью. Зарабатывая при этом достаточно, что бы выкупить землю в центре областного города и построить там частный дом. Завидуйте дальше :)
Поднадоели исходники С# и C++ в функциональном стиле, как приятно видеть старый добрый Паскаль
При этом кто-то продолжает спокойно, в своё удовольствие, работать с полюбившимся инструментом, не смотря на то, что его активно постоянно поливали и поливают грязью. Зарабатывая при этом достаточно, что бы выкупить землю в центре областного города и построить там частный дом. Завидуйте дальше :)
А мне нравится, что Delphi вызывает холивар — значит он до сих пор интересен людям и многие о нем знают. Некоторые и споривших даже пробуют Delphi, чтобы действительно понять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VCL, избавляемся от мерцания, раз и навсегда