Комментарии 82
Прочитав заголовок, надеялся в статье обнаружить описание особенностей языка с примерами в ООП, но этого нет. Надо было статью так назвать: "Lazarus IDE в 2024 году", и это было бы правильно.
И ObjPas и Delphi отличные языки. Недавно скачал понастольгировать Delphi 2010 и понял за что его люблю. Это максимальная экспрессивность!
можно ли через Lazarus создавать/править файлы и оформление MS Office/Libre Office под Linux? Где можно об этом почитать с примерами?
Посмотрите по этой ссылке, так же советую поспрашивать на англоязычном форуме. Можете попробовать на русскоязычном форуме спросить.
Люди занимались, но зачастую код теряется на просторах интернета.
Есть книжка: Корняков Василий "Программирование документов и приложений Ms Office в Delphi", БХВ-Петербург, 2005 (например).
Есть пара ссылок, но я не знаю, в каком состоянии эти библиотеки.
https://forum.lazarus.freepascal.org/index.php?topic=21868.0
На Паскале писал только в школе. И синтаксис конечно на любителя, begin...end и некоторая многословность в синтаксических конструкциях (видимо Вирт пытался сделать язык более похожим на английский?). Но ничего против Паскаля не имею. Думаю, когда хайп вокруг языка прекращается, всё наносное исчезает и остается настоящее. Приятно что энтузиасты создали среду Lazarus и развивают ее. Компактная, но вполне функциональная IDE очень выгодно смотрится на фоне тех многогигабайтных монстров, в которых сейчас превратились коммерческие среды разработки.
Однажды мне понадобилось провести какие-то эксперименты с самим языком, что-то с RTTI (я пишу некий труд, в котором сравниваю и анализирую фичи разных языков). И вот наткнулся на то, что там нужна версия fpc 3.3.1, а она почему-то еще не поставляется вместе с Lazarus. Увы, но везде сих пор используется 3.2.2.
FPC 3.3.1 находится в разработке с очень давнего времени. Не знаю по какой причине их разделили, но возможно это какая-то промежуточная "тестовая" версия. Которую можно скачать кто хочет, но стабильности (вроде как) не гарантируют. Многие изменения уже были занесены в последнюю стабильную версию.
Если сильно нужна версия FPC 3.3.1, то воспользуйтесь FPCUPDeluxe для установки этой версии. Хотя, сейчас наверно можно просто собрать FPC из командной строки. Я одну из версий FPC/Lazarus ради интереса и ставил используя командную строку. Вроде больших проблем не увидел.
А Lazarus, умельцы, вроде как настраивали на другие ЯП. ))) Может просто в качестве редактора, точно не скажу.
Можно же установить с любой версией fpc, с помощью fpcupdeluxe
я пишу некий труд, в котором сравниваю и анализирую фичи разных языков
можно как-то подписаться на результат Ваших изысканий?
И синтаксис конечно на любителя, begin...end и некоторая многословность в синтаксических конструкциях (видимо Вирт пытался сделать язык более похожим на английский?).
Вирт тут ни при чём: begin/end — это из Алгола, как, впрочем, и большая часть синтаксиса всех виртовских языков растёт именно из Алгола.
С RTTI функционал Lazarus достаточно урезан, в частности, основные методы TRttiContext. Если не ошибаюсь, перекрыты возможности искать тип по полному названию, как и альтернатива в виде прохода по всем типам тоже не реализована (есть просто коммент в исходном коде, что надежда умирает последней), как это сделано в Delphi. Это когда-нибудь будет исправлено, вы не в курсе?
Делфи, как много в этом звуке... я даже лицензию купил за 1,5куска. Из всего опробванного самое оптимальное по результату, когда нужен просто десктопный ехешник. Все эти богомерзкие куте даже рядом не стояли.
Будучи сам в далеком прошлом фанатом Borland Delphi, все же спрошу: в статье не написано главное - зачем читателю изучать современный Паскаль? Много предложений работы по нему? Или предложений мало, но программистов ещё меньше и поэтому они всегда нарасхват и с длинным рублем или даже, не побоюсь этого слова, юанем? Зачем?
Основное отличие современного паскаля мне видится в возможности разработки мобильных приложений и добавки разных упрощенных конструкций (если раньше надо было, скажем, inttostr(a) или booltostr(a), то теперь можно не париться и использовать просто a.ToString.
Насколько паскаль востребован в плане трудоустройства не скажу, так как не профессиональный программист, но в сисадминской практике мне Delphi помогает в быстрой автоматизации всякой рутины: как пример - выбрал из списка комп и пользователя, ткнул 2 кнопки и удаленка со сгенерированным паролем по RDP готова. За годы накопилась куча проектов - справочники, авторассылка временных ваучеров доступа к wifi и т. п. Т. е. можно быстро наваять практически любое приложение со скромными аппетитами, кроме, пожалуй, драйверов (и то, наверное, их тоже можно) и при этом без предустановки тонны всяких фреймворков.
Многие, насколько я знаю, используют этой сфере скрипты, но по уровню удобства интерфейса мне они кажутся неприемлемыми. Плюс скорость компиляции по сравнению с остальными испробованными вариантами (даже мобильных приложений) - просто бешеная.
В далёкие годы моего сисадминства/эникейства у нас был в отделе товарищ, который тоже всё автоматизировал через VC/MFC. Потом он уволился и после него осталась куча экзешников-в-себе, гора нечитабельного мусора вместо нормальных исходников и вот это вот всё. При том, что у нас на С++ вообще никто не кодил тогда.
Пришлось всё переписывать на скриптах (
Для автоматизации рутины сисадмина/девопса на порядок лучше Python или PowerShell, если для Windows. У них кол-во библиотек раз в сто больше, чем у паскаля.
Может библиотек для питона и больше, но вот ни разу не испытал недостатка на дельфи. И как на питоне сделать нормальный оконный интерфейс? Из того что я видел были только фреймворки разной степени сырости.
Я не брезгую писать cmd-скрипты для чего-то простого, но если удобнее работать в оконном интерфейсе я сделаю приложение. Можно конечно сделать что-то вроде "введите имя компьютера, а потом введите пользователя и нажмите enter", но мое решение мне кажется намного нагляднее и менее времезатратно.
Hidden text
1) Питон, да, имеет несколько библиотек для дектоп-UI, но я их не пробовал даже. Также есть несколько библиотек для web-UI и web-приложений, где исполняемый код и браузер у клиента разделены сетью/интернетом. Но
2) в подавляющее большинстве случаев никакого UI не надо, потому что все скрипты вызываются автоматически. Называется CI/CD, автоматическое управление инфраструктурой и прочее.
3) Сколько предложений по работе с десктопным-UI видно сейчас? Думаю, в пределах одного процента. Ну, кажется, это всё, что нужно знать. Кстати, я сам большой спец именно по десктопному UI, но признаю этот печальный факт про 1% и делаю выводы.
4) в приведенном примере: пользователи и компьютеры - очень много вертикального пустого пространства, в результате длинный вертикальный скрол. Текст для копирования - очень узкое окно с пустым местом справа, в результате ненужный четверной скрол по поризонтали в угоду ^красивости^.А можно ещё и word wrap сделать, чтобы без скрола вообще.
Я бы с вами может и поспорил и примеры привёл и в диалогах поучаствовал...
Но думаю у вас есть своё субъективное мнение и остальных вы просто не хотите "слышать".
>2) в подавляющее большинстве случаев никакого UI не надо
Непонятно как всё это вызывать "автоматически скриптами", у скрипта есть интеллект, который будет знать кому и с какими параметрами делать подключение? Чтобы он знал, это получается помимо скрипта должно быть другое интерфейсное решение, где пользователь уже сам выбирает компьютер/сервер к которому хочет подключаться, потом руководитель (который ни сном, ни духом в компах) должен подтвердить это. Получается ещё более громоздкое решение, но со скриптами, да.
4) в приведенном примере
Не знаю зачем я это объясняю, но над списками есть поля ввода, выводящие или выбранный элемент списка, если писать там руками, то работают как фильтр - в списке только подходящие записи. Текст для копирования необязательно выделять, в буфер обмена копируется по щелчку мыши. Плюс это решение для себя, меня не раздражает и ладно. Была бы куча пользователей - я бы учитывал отзывы, улучшал интерфейс и т. д., но пользователей всего 2 (я и второй админ) и все их пожелания учтены.
Как минимум для своего образования. Если человек хочет выбрать какой-то ЯП, то Паскаль далеко не худший выбор. Но это не значит что надо бежать изучать Паскаль и кричать что надо изучать именно Паскаль.
Всё то же самое что и с остальными ЯП.
Хотите знать, я зарабатываю используя Паскаль.
Рад за вас и за Паскаль, но дело не в вас, а в кол-ве предложений на рынке. Неужели не видите разницы? А изучать ещё один, похожий на другие, но очень мало распространённый язык не вижу смысла.
Читайте, пожалуйста, что вам пишут, а не выдумывайте какие-то свои выводы.
Никто, ни один человек не сравнил кол-во предложений на рынке и зарплаты в этих предложениях.
Слушай, это делалось уже много раз. И никто не спорит, что вакансий на делфи меньше, чем, например, на с#. Что тут сравнивать ещё? Зп? Зп одинаково, а медиана по ЗП даже выше временами.
У меня бот регулярно выводит статистику
Вакансий на HH:
Delphi: 221 (-3) ~105k (25-240)
Pascal: 78 (-1) ~60k (30-200)
Python: 3757 (-11) ~80k (17-250)
C#: 2190 (+7) ~70k (0-300)
C++: 2656 (+1) ~120k (19-350)
Swift: 445 (-9) ~150k (15-540)
Java: 3490 (-73) ~60k (0-150)
Visual Basic: 96 (+5) ~100k (25-200)
Go: 1243 (-1) ~150k (0-350)
Ruby: 142 (-2) ~130k (15-400)
Kotlin: 1057 (-8) ~100k (0-350)
Rust: 124 (0) ~150k (40-350)
Fortran: 3 (0) ~0k (0-0)
Dart: 152 (-3) ~120k (20-300)
Flutter: 252 (-4) ~100k (0-300)
FireMonkey: 1 (-1) ~80k (80-80)
Electron: 57 (-7) ~150k (50-330)
Lazarus: 11 (0) ~80k (32-140)
React Native: 223 (-4) ~120k (17-350)
1С: 6479 (-10) ~80k (25-350)Вакансий на делфи почти в 10 раз меньше, чем на с#, но всего в 2 раза меньше, чем на Свифт, почти в два раза больше, чем на раст, дарт, руби и столько же как на реакт.
Вилка не сильно отличается от других, а медиана выше многих.
Ну, во-первых, если у клиента есть потребность в решении, то никто не запрещает тебе написать его на Delphi. Клиент быстро получит решение и будет доволен.
Во-вторых, много компаний которые не только используют Delphi, потому что кто-то когда-то им его создал и нужно допиливать, но и потому что создают новые решения на современном Delphi. Несмотря на все тенденции в языках, софт на Delphi создается очень быстро и требует меньше внимания в будущем, потому что нет никаких зависимостей. Я до сих пор могу на Win11 запустить софт на Delphi 20ти летней давности и он ни слова не обронит и будет без проблем работать.
Где-то 10 лет назад, я написал свой первый коммерчески-успешный продукт для одного заказчика. С тех пор, он обращался ко мне лишь несколько раз, первые два раза - это были баги в расчетах, которые нужно было поправить, и два раза были обращения на добавление новых фич. До сих пор этот софт у них работает. А программа была не простая. Там и бд и сложные расчеты и 3D моделирование. Это была программа для расчета огромных ящиков по ГОСТу с изменяющейся моделью в реальном времени, базой заказчиков и историей их заказов. Программа создавалась ещё для XP, но они сами без проблем установили её на Win10, а сейчас может уже и на Win11. Программа обошлась им где-то в 300к + 100к на две новые фичи, а пользуются они ею уже 10 лет. Насколько это выгодно? Особенно, если бы это было какое-то решение на Web. А я потратил на эту программу где-то 3 месяца (параллельно с основной работой) + неделя.
На текущем рабочем месте я стал инициатором создания нового софта на Delphi и использования современных версий языка. Под моим началом переписан бэкенд некоторых сервисов с Питона на Делфи, что решило много проблем с производительностью сервисов и сократило время на добавление новых фич сервиса (последнее вероятно просто связано с архитектурой).
Также, на работе я поспорил с тех. лидом, что напишу мобильное приложение для просмотра 3D панорам быстрее, чем наши разработчики на Unity. И написал. В итоге, именно моё решение сейчас находится в некоторых магазинах Леруа Мерлен.
Много доводов, не имеющих отношения к языкам как таковым.
Это почему? Сам по себе язык мало что определяет. Мы говорим именно об инструменте. Вы сами написали про "Borland Delphi", сейчас это "RAD Studio" - инструмент, который позволяет создавать кроссплатформенные решения, красивые и современные GUI и что угодно по функционалу не менее удобно, чем в других инструментах.
Сам язык Delphi на месте, со времен Borland, не стоял, а развивался и развивается по сей день. Сейчас в бете находится новая минорная версия RAD Studio 12.1. Развивают как язык (добавляя в том числе новые конструкции синтаксиса языка), так и IDE и рантайм библиотеку и штатные фреймворки (их там теперь два: старый добрый VCL и кроссплатформенный - FMX).
Язык использовать просто, инструменты многое позволяют, быстро или даже быстрее, чем другие инструменты.
То, что вакансий на том же hh по Delphi меньше, чем на популярные языки - всем известно. Особой проблемой это не является. Я в своё время побывал в разных частях страны и без особых проблем находил себе работу на Delphi и нигде я не был вынужден заниматься только "легаси". Конечно, во многих компаниях есть долгоживущие проекты, это разве плохо? Нет. Плохо, когда ты вынужден каждые несколько лет переписывать всё с нуля, потому что то уже устарело и не работает.
Я бы ответил на этот вопрос так, хотя ответ будет лежать через призму собственного опыта, который уже устарел. Когда то давно, а я из категории old school, из тех старых романтиков, которые думали (когда мне было лет 16) что Бил Гейтс сам MS DOS написал (винды ещё тогда не было), а Питер Нортон сам написал утилиты Нортона. И я когда то хотел создать нечто, чтобы стать как эти "великие люди". И само собой мы вели с "коллегами" флеймовые войны, какой язык круче. Я был приверженцем Си и Си++, не сказал бы что я гнобил паскаль, но уже в то время я считал его устаревшим. А однажды мой наставник (его уже и в живых давно нет), сказал, настоящий программист должен свой язык написать. И это засело у меня в голове, я ответил: "Точно, так и надо сделать". Все самое интересное началось когда я вернулся из армии, вместо MS-DOS появилась какая то Винда 95тая и надо было что-то с этим делать. А т.к. была востребованность в базах данных, однажды студенты мне подсказали, что есть такой продукт как Borland C++ Builder. Продукт показался мне абсолютно фантастическим, в одиночку можно было заворачивать проекты невероятных масштабов. В какой-то момент мне понадобились компоненты, решил писать сам. И тут я обнаружил, что все компоненты написаны в Delphi, на C++ Builder их не кто не пишет. Начал осваивать Delphi... И чем дальше погружался в процесс, тем чаще ловил себя на мысли, что в Паскале удобнее и понятнее.. В конце концов на C++ я уже не вернулся, мои стереотипы о Си и Паскале перевернулись. Прошло много лет, поменялись тенденции, всё движется в web. Но для меня ни чего не изменилось, могу только сказать что написал своя язык, понадобилось 20-25 лет и только после приобретения книги Вирта "Построение компиляторов", дело сдвинулось, до этого просто не хватало информации, произошло это в 2014 г. За это время Паскаль в виде Delphi и FPC оброс всевозможными библиотеками и для мня опять же, мнение не изменилось, с паскалем - один в поле воин.
Как раз Делфи более прогрессивный, чем С/С++, потому что в нем есть интерфейсная часть, которая компилируется в отдельную сущность и убирает необходимость в давным давно устаревших h-файлах. Но дело именно в том, что "один в поле войн" в корпоративной разработке (и в любых больших проектах) вообще не актуально. Всем нужны грамотные групповые игроки. А свой пет-проект можно писать хоть на чем.
Кто бы что не говорил, а на FPC можно изготовить почти всё что угодно. Я автоматизирую бизнес, использую в работе собственную платформу Дизель-Паскаль, изначально написанную в Delphi, затем портированную на FPC/Lazarus. В основе системы - собственный интерпретатор компилирующего типа с 2х объектно-ориентированных языков с подвязанной к системе библиотеке компонентов LCL. Это позволяет запускать приложения Дизеля на разных платформах без перекомпиляции (x86-64 Windwos, Linux, Aarch64 Linux), а наличие всевозможных компонентов для FPC, позволяет реализовать на FPC почти всё что душе угодно. Я сам использую:
- доступ к FireBird, Postgres через компоненты IBX, ZEOS,
-для построения отчетов LazReport (правда пришлось допилить для QR кодов и DataMatrix).
-электронные таблицы - fpSrpeadSheet, позволяет выводить отчеты в Excel, ooCalc и читать данные из этих форматов, причем наличия установленного какого либо офисного пакета вообще не требуется.
-обмен данными по http, ftp, эл.почта и т.д. через библиотеку Synaplse. А т.ж. черз тот же Synapse по tcp протоколу с разными устройствами.
- web сервисы через fpWeb (можно и на synapse сделать), обмениваюсь данными через web сервисы с 1С, раздаю отчеты по http.
-замечательные парсеры xml и json
В общем всё что нужно для автоматизации бизнеса в FPC есть, а феноменальная переносимость программ с графическим интерфейсом позволяет переносить приложение на множество платформ. Как я и говорил, изначально проект был основан на Delphi и я даже её покупал, как и сторонние компоненты. Портирование на FPC позволило избежать лицензионных зависимостей, да, что-то пришлось допилить, но теперь я не прибит гвоздями к Windows.
Delphi уже давно не прибит гвоздями к Windows, а только среда разработки RAD Studio. И софт можно создавать куда презентабельнее, чем это позволяет LCL.
Я рад за Delphi, я так долго ждал кросс-платформенности, так и не дождался, надеялся на Kylix но его закопали. Но среда то всё равно прибита к win, к тому же в Delphi много ограничений на использование интерфейса дизайнера, не говоря уж о платности самой RAD Studio, а в Lazarus, я вообще могу любые его компоненты использовать, например, в какой-то момент, я отказался от собственного инспектора объектов, и просто использую тот что поставляется с Lazarus.
В Delphi + FMX необходимость в других компонентах вообще отпадает. Я могу создать сам что угодно не прибегая вообще к созданию контрола отдельно. Потому что в FMX есть стили (нет, это не скины или темы). В FMX любой контрол может иметь любое представление в любой момент времени и выглядеть как угодно и даже не просто выглядеть, но и обладать новыми функциями.
Например, если я захочу, чтобы у меня в поле Edit была кнопка - я просто вставлю туда кнопку. А если хочу, что несколько Edit были такими, я создам стиль для Edit и добавлю в него кнопку, а потом применю этот стиль к тем Edit которым захочу.
Если я захочу иметь кнопку с Split частью, т.е. кнопку разделенную на две кнопки - я просто создам такой стиль и буду иметь возможность сколько угодно таких кнопок иметь и всё это без вообще строк кода. Если я хочу иметь список из сложных элементов, я могу сделать это десятком способов, могу запихать фреймы и каждый элемент будет фреймом, могу привязать датасет к списку и создать стиль для элементов этого списка и выводить любую информацию в любые элементы стиля.
Я могу создать стиль, который будет выглядеть как приложение созданное на WinUI 3.
Всё что здесь отображено - это всё одни и те же штатные контролы, имеющие разные разные представления
Всё что предоставляет мне RAD Studio с головой хватает для создания вообще любых интерфейсов. Я уже не один раз создавал приложение на основе проекта Figma, созданного для веб сервиса.
Да,красиво, удобно, особенно с кнопками в Edit. Но по своему опыту могу сказать, что самое главное, чтобы программа имела свое лицо и была узнаваемой. Как бы красиво это не было, я уже обратно на Delphi точно не вернусь, да и покупать дорого а воровать не хочется. Ну и лицензионные ограничения, чтобы использовать интерфейс дизайнера форм Delphi, это не так просто всё. И сейчас, приложения для бизнеса я создаю в Дизель-Паскаль. Он достаточно компактен, на любом рабочем месте, будь то Windows, Linux, aarch, x86, в случае какой-то засады, я могу открыть приложение в дизайнере и использовать отладчик.
Покупать не дорого, если уже имеешь доход, а если дохода нет, то и среда разработки для тебя бесплатная. Есть версия Community Edition, по возможностям приравнивается к Pro версии. Позволяет использовать Delphi бесплатно, если доход не превышает $5k в год.
Плюсом ко всем красотам нужно добавить то, что при любом DPI экрана, картинка будет масштабироваться пропорционально, не теряя качества и без расползания разметки (если стиль векторный, конечно же, как у меня тут).
Всё что предоставляет мне RAD Studio с головой хватает для создания вообще любых интерфейсов.
И web-интерфейсов тоже?
Web-like интерфейсов - да.
Не понимаю, это как?
Самая большая проблема Delphi/Lazarus в том что для создания интерфейса необходимо использовать визуальный редактор и нет возможности набирать визуальную часть руками т.е. в виде подхода code-first. Я когда в свое время с большим бекграундом Pascal/Delphi перешел в Web и на другие desktop платформы понял что визуальное представление скорее мешает чем помогает в разработке. Все более современные на тот момент платформы разработки уже перешли на вариант когда ты описываешь визуальный интерфейс в виде HTML/XML/CSS/JSON/YAML/.. декларативного кода. В Delphi/Lazarus тоже есть такой вариант в виде dfm/lfm/fmx файлов но средства для адекватного редактирования этих файлов в среде разработки нет. На мой взгляд добавление такого средства или добавления декларативного языка помогло бы языку стать более современным средством разработки.
Ерунду говорите. Никаких проблем построить интерфейс в рантайме ни там, ни там - нет.
"построить интерфейс в рантайме" если Вы про то что можно просто кодом создавать компоненты то нет простите это еще менее удобней. Давайте я Вам на примере покажу, вот допустим я решил скинуть своему тиммейту кусочек дизайна страницы как пример решения
В случае допустим XAML я скину следующее:
<StackPanel>
<muxc:PipsPager x:Name="FlipViewPipsPager"
HorizontalAlignment="Center"
Margin="0, 12, 0, 0"
NumberOfPages="10"
SelectedPageIndex="3" />
</StackPanel>В случае QML я скину следующее:
Rectangle {
width: parent.width - 80
height: 180
anchors.centerIn: parent
color: applicationThemeViewModel.pageUpperPanel
radius: 8
}В случае HTML я скину следующее:
<span>
<font color="red">ALERT!!!!</font>
</span>Теперь проверните такой трюк с Delphi/Lazarus/RAD Studio... Сделаете скриншот Object Inspector? Сделаете скриншот Structure? Сделаете скриншот Form Designer? Или всего сразу?
Тоже самое касается документации в которой нет кода, там сплошные скриншоты вышеупомянутых окошек. Это относиться к таким моментам что нельзя открыть на гите и понять что у тебя там на форме без RAD Studio (нельзя сделать фикс в блокноте или любом другом текстовом редакторе за пределами RAD Studio) и много других казалось бы маленьких моментов из-за которых удобство убивается. Еще раз я не говорю что язык плохой, среда плохая и в целом инструмент плохой и все это не развивается, я говорю что конкретно этот аспект остался таким каким был еще со времен Delphi 5 (когда я впервые начал на нем разрабатывать) и не менялся чуть более чем полностью. Подход "редактируем дизайн только в дизайнере" это уже устаревший подход. Сейчас программисты для дизайна используют декларативные языки а если прям есть настоящие дизайнеры в команде то для них есть специальный отдельный продукт где да все редактируется в визуальных дизайнерах, такое есть и в Visual Studio(Blend) и в Qt(Design Studio) и много где еще.
Нет, я просто возьму и скопирую ту часть прямо в дизайнере и вставлю в мессенджер. Потому что копия части интерфейса - текст. И его можно вставить обратно на форму
object Button1: TButton
StaysPressed = True
DisableFocusEffect = True
Images = ImageList24
ImageIndex = 5
Position.X = 128
Position.Y = 54
Size.Width = 101
Size.Height = 32
Text = 'Label'
TextSettings.HorzAlign = Leading
TextSettings.Trimming = None
object Label103: TLabel
Align = Client
StyleLookup = 'labelstyle_badge_container'
TextSettings.WordWrap = False
Text = '1'
end
endВот это можешь скопировать и нажать Ctrl+V на форме или любом контроле
Получаем
И в любой момент ты можешь просто взять и посмотреть код твоей формы. Изменять, удалять и создавать новые элементы. Можешь просто взять и заменить целиком класс (лишние свойства удалятся). Я так постоянно делаю, когда занимаюсь дизайном стилей. Нужен мне фон и его эффекты в одном контроле, но фон нужен не в виде Circle, а в виде RoundRect, скопировал в блокнот, заменил TCircle на TRoundRect, забрал из блокнота и вставил куда нужно.
Но с нуля форму писать текстом нет никакого смысла. Гуглить каждый класс контрола, писать вручную все его свойства. Накой черт этим заниматься, если можно просто выбрать из списка, увидеть все доступные свойства и изменить на свой вкус? И при этом я не имею никаких ограничений, который ты выдумываешь. Дизайнер лишь сам за тебя пишет код. Только быстрее и точнее.
И в любой момент ты можешь просто взять и посмотреть код твоей формы. Изменять, удалять и создавать новые элементы.
Уж простите но как это не вяжется с
Но с нуля форму писать текстом нет никакого смысла. Гуглить каждый класс контрола, писать вручную все его свойства. Накой черт этим заниматься, если можно просто выбрать из списка, увидеть все доступные свойства и изменить на свой вкус?
Т.е. ничего создавать и изменять Вы не сможете без дизайнера. И более того все значения всех свойств Вы тоже не знаете что сводит смысл в каком-либо редактировании этого текста на нет (ну кроме каких-то минимальных вещей).
И при этом я не имею никаких ограничений, который ты выдумываешь.
Редактирование формы через блокнот смахивает на ограничение. Уж простите но вообще то среда разработки должна иметь средство редактирования таких файлов внутри себя, иметь подсветку синтаксиса, подсветку ошибок а также автодополнение имен классов и свойств и этого всего в RAD Studio нет. Просто Вы занимаетесь странными вещами что-то там редактируя через блокнот и просто не видите что это является проблемой. Возможно для Вас это не проблема конечно но со стороны это выглядит странно.
Вот это можешь скопировать и нажать Ctrl+V на форме или любом контроле
Images = ImageList24Что это такое? и что я получу скопировав это? У меня нет этого компонента:)
Position.X = 128
Position.Y = 54
Size.Width = 101
Size.Height = 32Моя форма может быть меньше/больше переданных размеров то что тогда?
object Button1: TButtonЧто если на моей форме уже есть Button1?
Что не вяжется?
Редактировать форму ты можешь текстом.
В полной мере ты можешь сделать все через текст, потому что текст является конечным результатом, а не дизайнер. Программа в конечном итоге использует именно текст. Который ты можешь редактировать, даже не открывая дизайнер. С подсветкой синтаксиса и всем прочим.
Здесь все понятно?
Блокнот упомянут тут для того, чтобы дать понять, что это не какой-то абстрактный редактор дизайна, но в виде текста, а обычный текст. Естественно, если мне нужно изменить класс, я могу просто перевести дизайнер в режим отображения кода дизайна и изменить название класса.
В остальном никаких отличий от ваших "преимуществ" нет. У вас есть лишь недостаток - отсутствие визуального дизайнера интерфейса. А тут есть и дизайнер и возможность его описывать текстом.
Нет такого компонента - он про игнорируется.
То, что у тебя форма меньше - не играет никакой роли. Он вставится и будет по тем координатам. Не нравится измени. Абсолютные координаты - это не единственный способ позиционирования.
Если у тебя уже есть Button1, он станет Button2 или другая другая цифра в сочетании с названием класса.
Все эти, выдуманные вами, проблемы есть и в ваших примерах выше.
Повторю ещё раз. Если у вас только декларативный вариант интерфейса, то в делфи тот же декларативный + есть отдельный инструмент делать это визуально.
Окей не для разогрева спора и не для "выдумывания" давайте тогда более предметно говорить. Скачал триал Delphi, версия ниже на скрине:
Который ты можешь редактировать, даже не открывая дизайнер. С подсветкой синтаксиса и всем прочим.
Я правильно понимаю что Вы говорите вот об этом? Если перейти в этот режим (назовем "режим dfm" а обратный "режим формы") то да открывается dfm файл и в нем есть подсветка синтаксиса. Авто дополнение не работает (пробовал Ctrl+Enter/Ctrl+Space/Ctrl+Shift+C). Ошибки не подсвечиваются в тексте, и проверяются ошибки только если перейти обратно в режим формы. Сообщения об ошибках отображаются только внутри диалогового окна. Ну и самое главное а куда девается визуальная форма и почему содержимое Structure и Object Inspector куда-то исчезает? Т.е. остается активным только текстовый редактор с dfm.
Итак теперь давайте просто сравним с чем-то другим ну потому что мы тут про сравнения же. Итак вот как тоже самое выглядит где-то еще:
Тут у меня открыто редактирование разметки и это полноценный редактор с автодополнением "и прочим", и да ошибки прямо в коде подсвечиваются. При этом и визуальный дизайнер доступен и Toolbox (тоже самое что Object Inspector), можно и через него добавлять и через код и оно синхронизируется. Если я в коде что-то добавляю то сразу вижу изменение в визуальном представлении.
Итак что у нас в сухом остатке:
Авто дополнения нет
Подсветка ошибка в коде нет, вместо этого необходимость для проверки переходить в режим формы и читать ошибки в диалоговом окошке
Просмотр изменений в визуальном редакторе сразу после изменения текста нет, для просмотра каждый раз надо переходить в режим формы
Пользоваться Structure и Object Inspector нельзя
Я допускаю что возможно можно что-то настроить чтобы что-то из выше перечисленного начало работать (укажите где я еще раз посмотрю) или возможно чего-то не хватает из-за того что триал версия.
Всё это, потому что никто в здравом уме не будет лезть в текстовый режим формы. В этом нет никакого смысла. Если вы в WPF не можете всё сделать в дизайнере, то в Delphi абсолютно всё можно сделать в дизайнере. От и до. Не говоря уже о том, что в FMX два дизайнера (для формы и для представления (стиля)).
Именно по этому никто не запрашивает проверки ошибок или подсказки. Возможность зайти и что-то исправить текстом - есть, а больше ничего не нужно. Всё, абсолютно всё, можно сделать в дизайнере и сделать это на порядок быстрее. И всё работает в дизайнтайм, в отличие от WPF (даже биндинги, они тут тоже есть и работают "на горячую").
Биндинги есть и для датасетов и списков, и между моделями данных и контролами, и между датасетами и контролами (другими словами можно что угодно с чем угодно связать)
Наконец-то мы вышли на одну волну. Итак теперь давайте пойдем прочитаем мое самое первое сообщение в этом треде.
Самая большая проблема Delphi/Lazarus в том что для создания интерфейса необходимо использовать визуальный редактор и нет возможности набирать визуальную часть руками т.е. в виде подхода code-first.
И имел я в виду не вот это:
Именно по этому никто не запрашивает проверки ошибок или подсказки. Возможность зайти и что-то исправить текстом - есть, а больше ничего не нужно.
А полноценное создание/редактирование форм через код с полной интеграцией этого процесса в среде разработки. И этого в Delphi нет, что значит что я указал не на "выдуманное преимущество" а на реальную проблему. Что также значит что все мои тейки дальше полностью корректны. Спасибо что подтвердили это.
Если вы в WPF не можете всё сделать в дизайнере, то в Delphi абсолютно всё можно сделать в дизайнере. От и до.
В WPF также можно сделать все с нуля только в дизайнере.
Всё, абсолютно всё, можно сделать в дизайнере и сделать это на порядок быстрее.
Если сравнивать редактирование текста (с автоподсветкой, автоподстановкой и прочими фичами) и использование дизайнера, то редактирование текста будет почти всегда быстрее. Сравниваем: надо поменять title у компонента. В редакторе коде просто переходим на нужную позицию в тексте и пишем новый. В дизайнере надо вначале перейти в дизайнер если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новый. Просто даже по количеству действий второй подход уже проигрывает.
И всё работает в дизайнтайм, в отличие от WPF (даже биндинги, они тут тоже есть и работают "на горячую").
Все работает в design time и в WPF.
А полноценное создание/редактирование форм через код с полной интеграцией этого процесса в среде разработки. И этого в Delphi нет
Редактор есть, пиши. Нет функций - запроси. Никто не требовал их, их не создали
В WPF также можно сделать все с нуля только в дизайнере.
Нет нельзя, те же бинды там делаются исключительно в xaml
Сравниваем: надо поменять title у компонента. В редакторе коде просто переходим на нужную позицию в тексте и пишем новый. В дизайнере надо вначале перейти в дизайнер если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новый. Просто даже по количеству действий второй подход уже проигрывает.
Как хитро вы завернули "переходим на нужную позицию в тексте". А сколько там шагов при большой форме?
В Делфи - это. Ткнул на форму, вписал название. Тем более, что даже в свойства заходить не надо, можно нажать ПКМ и изменить значение основных полей.
Перевожу ваш "короткий путь" в реальный:
В xaml надо вначале перейти в xaml если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новое значение.
А вот поиск нужного компонента в тексте куда дольше, чем поиск его на форме, прям перед глазами. Ты его видишь вот прямо сразу.
Нет нельзя, те же бинды там делаются исключительно в xaml
Редактор есть, пиши. Нет функций - запроси. Никто не требовал их, их не создали
Я уже не понимаю или Вы действительно не понимаете о чем я пишу либо Вы троль. К слову я писал запросы на эту 12 лет назад и не один. Сделали?
Перевожу ваш "короткий путь" в реальный:В xaml надо вначале перейти в xaml если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новое значение.
Нажал Ctrl-F ввел title в поисковое поле нажал Enter, сразу оказался где надо и даже сам title уже введен что позволяет удалить его просто начав писать.
Ооо, замечательное окно. И где удобнее? В RAD или в VS? А поиск компонента по названию, уж смешно) Он и в дизайнере есть
Ооо, замечательное окно. И где удобнее? В RAD или в VS?
Поставьте студию и сравнивайте
А поиск компонента по названию, уж смешно) Он и в дизайнере есть
Сквозной поиск по названию (чего угодно), значению и любых их сочетаний, использование регулярных выражений причем как в одном файле так и нескольких, плюс все выше перечисленное можно использовать для замены. Все это есть в дизайнере?:)
О супер, если приходится искать контрол через регулярки - то очевидно, инструмент так себе
Гениальный вывод. Железная логика. Браво. Полагаю что когда Вам нечего ответить но вроде как надо да еще и остаться в парадигме "Delphi круто, остальное фигня" вполне можно сделать какие угодно выводы, апеллировать к каким угодно вещам. Вы так делаете уже 5 сообщений подряд вместо аргументов высказываете информационный шум. Наша дискуссия закончена, не вижу смысла ее продолжать все равно толку от нее никакой.
Просто для информации. И сразу говорю, что для Delphi вероятнее всего многое подобно.
В Lazarus существуют файлы lfm, в Delphi - dfm. Дальше многое что относится к lfm-файлу можно отнести и к dfm-файлу.
lfm-файл спокойно редактируется вручную и зная все свойства компонентов мы можем полностью собрать всю форму вручную. Но не забываем что перебирая lfm-файл нам надо обязательно компонент добавить в сопутствующий модуль.
Поэтому да, изменять всю визуальную часть мы вполне можем вручную, даже уже у выставленных компонентов. Чтобы этим не заниматься, Lazarus предоставляет средства визуального редактирования файлов, где можно выставить не только местоположение и какие-то основные данные для визуального отображения, но и почти все свойства для данного компонента и необходимость в ручном редактировании практически отпадает (не всегда!).
Для сравнения!
Используя Eclipse и Android Studio так же проще работать с визуальной составляющей, но, насколько я заметил, тут нет того функционала какой есть в Lazarus и нельзя полностью (хорошо, в большей мере) редактировать все свойства визуального компонента, из-за чего приходится многое делать вручную.
Просто для информации. Подход code-first это когда я могу проводить 100% времени в текстовом редакторе формы и мне ни разу не понадобится ни для одной вещи открывать дизайнер.
lfm-файл спокойно редактируется вручную и зная все свойства компонентов мы можем полностью собрать всю форму вручную.
Можем, вот по лично Вашему опыту, сколько раз Вы и/или Выши знакомые разработчики так делали? Т.е. является ли это просто опциональным режимом или же это мейнстрим подход разработки?
И кстати в Lazarus в редакторе формы есть автоподстановка, чего нет даже в Delphi. За это респект авторам Lazarus.
Я использовал это для переноса проекта Delphi в Lazarus. Очень маловероятно что этим будет пользоваться кто-то ещё, ведь в основном это нужно только для редактирования вещей, которые вызывают ошибку в данном модуле и должно это произойти из-за файла *.lfm.
Я же уже написал, данный дизайнер содержит практически все настройки, которые уже не надо прописывать вручную, а можно просто установить.
Да, можно в коде, без использования файла *.lfm прописать все свойства для формы. Вручную добавить кнопки, прописать их данные, связать их между собой по необходимости...
Да, можно, но тут как раз и возникнет вопрос: "А зачем?"
Всё сделано для пользователя, чтоб он не мучался и видел конечный результат. Да, кому-то это не нравится (мне в том числе), но большинство может достаточно быстро сделать необходимый макет и уже от макета создавать необходимый код.
Визуальная составляющая очень сильно вытягивает данные среды разработки.
lfm-файл спокойно редактируется вручную и зная все свойства компонентов мы можем полностью собрать всю форму вручную.
Очень маловероятно что этим будет пользоваться кто-то ещё, ведь в основном это нужно только для редактирования вещей, которые вызывают ошибку в данном модуле и должно это произойти из-за файла *.lfm.
Дак "спокойно редактируется" или "Очень маловероятно что этим будет пользоваться кто-то ещё" ?
Я же уже написал, данный дизайнер содержит практически все настройки, которые уже не надо прописывать вручную, а можно просто установить.
Еще раз, моя мысль следующая - в аналогичных средах разработки (каких уже упоминал в первом сообщении) если выбор когда я могу делать все через дизайнер или делать все через код (не код OP! а декларативный код). Т.е. мы можем использовать дизайнер или код и эти способы разработки равнозначны и полностью взаимозаменяемы. Т.е. у меня есть выбор либо я пишу код, либо я использую дизайнер, не исключена комбинация в любых пропорциях. В Delphi/Lazarus выбора нет, Вы либо используете дизайнер либо используете дизайнер. Да можно, но можно != удобно и функционально, редактировать код формы но сейчас это выглядит как режим пришитый сбоку.
В Delphi/Lazarus выбора нет
то есть вы подтверждаете, что вы не читаете что вам пишут? Я конкретно сказал, что можно делать так, как захочешь, если умеешь это делать!
Дак "спокойно редактируется" или "Очень маловероятно что этим будет пользоваться кто-то ещё" ?
Что именно не нравится в ответе? Что мешает редактировать, при том что маловероятно этим будешь заниматься?
то есть вы подтверждаете, что вы не читаете что вам пишут? Я конкретно сказал, что можно делать так, как захочешь, если умеешь это делать!
А Вы подтверждаете что не читаете что я Вам пишу и уже повторил один и тот же тезис кучу раз но Вы его не видите?
Что именно не нравится в ответе? Что мешает редактировать, при том что маловероятно этим будешь заниматься?
Если инструмент нужен для того чтобы иногда что-то там подредактировать а не пользоваться постоянно то и функционала в нем будет соответственным образом а значит пользоваться им на постоянной основа будет неудобно.
А Вы подтверждаете что не читаете что я Вам пишу и уже повторил один и тот же тезис кучу раз но Вы его не видите?
Это ответ, ради ответа. Сути ни какой не несёт, банальная попытка оправдать себя.
Если инструмент нужен для того чтобы иногда что-то там подредактировать а не пользоваться постоянно то и функционала в нем будет соответственным образом а значит пользоваться им на постоянной основа будет неудобно.
Для постоянного использования и сделан другой функционал, тот, который предоставляет полноценную замену.
Ни Lazarus ни Delphi не обязаны использовать тот же функционал, что используется в других языках. Ни один язык не пошёл по стопам Паскаля, и это их выбор. То что вы пишите, это так же очередная попытка оправдать самого же себя (свои слова).
Я думаю что дальше стоит вообще продолжать диалог, вы зациклены на своей стезе, в которой видимо застряли и не хотите признавать какие-то другие подходы.
Это ответ, ради ответа. Сути ни какой не несёт, банальная попытка оправдать себя.
Мой тезис: режим редактирования формы в редакторе обладает небольшим функционал (даже сравнивая с редактором Object Pascal) а также не интегрирован с режимом дизайнера, Object Inspector прочими вещами, и предназначен не для полноценного написания кода форм с нуля (что подтвердили и Вы и Ваши коллега в соседней ветке) а для правок в разных случаях когда дизайнер не может загрузить форму или просто разных небольших правок.
Ваш тезис: ну редактор формы есть значит в нем все можно делать и если я не могу там что-то делать то дело не в нем (в том что там мало функционала) а во мне.
Ни Lazarus ни Delphi не обязаны использовать тот же функционал, что используется в других языках. Ни один язык не пошёл по стопам Паскаля, и это их выбор.
Причем тут Паскаль? Я говорю исключительно о среде разработки и декларативном языке описания форм.
и если я не могу там что-то делать то дело не в нем (в том что там мало функционала) а во мне.
Это ответ вам же. На любом другом ЯП будет абсолютно то же самое, если будет нормальное графическое редактирование. С полными функциональными возможностями.
И это не будет зависеть от вас, это будет зависеть от знаний человека, который с этим столкнётся. А точнее с каждым днём людей, которые будут редактировать форму вручную, будет всё меньше и меньше. И знаний о том, что её можно редактировать будет всё меньше и меньше. Пока человек не поинтересуется этим.
Повторюсь: при этом, в Lazarus и в Delphi есть возможность редактирования формы вручную. Как отдельный файл, так и в коде!
Причем тут Паскаль? Я говорю исключительно о среде разработки и декларативном языке описания форм.
При том, что вам уже ответили, что такая возможность в Lazarus и Delphi существует. Писали об этом уже не один раз.
Начинал я программировать ещё со Спектрума
Наш человек.
Я бы посоветовал переходить на шарпы, тем более что автор дельфей и шарпов один)
Object Pascal в 2024-м