возвращение к программированию

[Снег Север]

А это уже вопрос эргономики. Точно так же, как у летчиков, например. Самые важные приборы - в центре, крупно, вспомогательные - на периферии приборной панели. Точно так же строится грамотный UI - интерфейс пользователя. Задача нетривиальная по своей сути, конечно. Но с современными графическими окнами, меню, панелями закладок и прочим создать такой интерфейс технически намного легче, чем в старых программных средах.

[debi12345]

Тем более что, в отличие от старых времён, когда на создание одного только окна требовалось полсотни строк кода, сегодня окна и все управляющие и вводящие-выводящие информацию компоненты создаются мановением руки. При этом то, что Вы создаёте, Вы видите немедленно, не теряя ни секунды на компилирование и запуск программы.

Кстати в Лазаре и МСЕ оооочень-оооочень не хватает именно рисования ГУЙ в коде - как это сделано наприклад в ФП-ГУЙ (описание всех ГУЙ-пропертей в одной строке, по типу ТСЛ/ТК)

[V.Pozyvnoy]

Доброе утро, друзья.
Нашел материал в интернете, вводный. Там дано очень краткое но в доступном понимании описание работы в среде и в общем начала. Теперь тестирую работу некоторых компонент. Примерно понятна суть. Вовлеченные в программу компоненты живут дальше своей жизнью и в некоторых компонентах можно переопределять значения свойств других. Т.е. в программе не нужно организовывать опрос.
Думаю математическую часть делать и отлаживать в freePascal и оформлять в виде процедуры, в отдельном файле к программе на Lazarus. Если не будет получаться буду спрашивать.

[Снег Север]

По математике - если вы еще не видели, тут есть хорошая статья про математические библиотеки для фрипаскаля - http://freepascal.ru/article/freepascal/20190506080000/
Еще у меня есть моя собственная адаптация под паскаль фортрановских и некоторых других математических программ - СЛАУ, Рунге-Кутт, численное интегрирование и т.п. Могу поделиться, если интересно.

[Cheb]

Поправьте меня, если ошибаюсь, но мне казалось, что на текстовую IDE давно плюнули, т.к. ей не пользуются потому что Лазарус удобнее. И, соответственно, поддержка у текстовой IDE отвратная.

Я в своё время написал на Турбо Паскале 3d игру, причём многопоточную (собственная реализация через прерывание таймера). С тех пор продолжаю писать игровой движок для следующей.
Хочу от себя добавить, что вполне можно использовать Лазарус в качестве рабочей среды, а программу под ним писать на голом Паскале, без всяких визуальных форм - в частности, мой движок.

Также должен предупредить про боль с кодировками: у винды 1251, а у консоли-866, из-за чего WriteLn('привет'); давал кракозяблы в фпц 2.х . Это в 3.х исправили, зато много другого поломали. И не торопятся чинить из-за того, что подавляющее большинство пользуется Лазарусом, где поверх всего этого - костыли, исправляющие проблему.

[Vadim]

Cheb
По поводу кодировок, Lazarus как IDE действительно выше всяких похвал - в винде сегодня аж три действующих кодировки: 866, 1251, UTF-16. Lazarus их все понимает и может, в случае необходимости, ставить как базовую. У текстовой IDE база не пойми что: вместе с модулем CRT 1251, без CRT - 866...

Добавлено спустя 7 минут 34 секунды:
V.Pozyvnoy
У нас тут есть хорошая книжка по основам использования Lazarus:
http://www.freepascal.ru/download/pdf/o ... azarus.pdf
Хотя там описан Lazarus совсем старенький, но основы работы практически не поменялись. Читать и руководствоваться ею можно без проблем.
Так же коллеги из Донецкого университета написали замечательный учебник:
https://docs.altlinux.org/books/freepascal.pdf

[V.Pozyvnoy]

Vadim
Вадим, спасибо! Хороший материал мне очень пригодится.

[Vadim]

Кстати в Лазаре и МСЕ оооочень-оооочень не хватает именно рисования ГУЙ в коде - как это сделано наприклад в ФП-ГУЙ (описание всех ГУЙ-пропертей в одной строке, по типу ТСЛ/ТК)

Типа KOL?

[Pavia]

Да. Писал решение математических задач. Некоторые результаты представлял как итог в графической форме. И сейчас хочу исследовать большой массив из случайных чисел. Поискать образующиеся аномальные плотности. Попытаться понять их природу, определить есть или нет закономерности их образования и может быть увидеть их влияние на последующее.
Я посмотрел на Лазарус. Первое впечатление угнетающее.

Лазарус он по началу страшный. Кладете на форму TButton - кнопка и TChart график далее смотрите видео урок.
И TImage для рисунков.

Пока вы не выведете график вы ничего не поймете что у вас там творится и что получается.

У меня тоже своя библиотека. Вчерась всю ночь на 64 бита переделывал. (Наверно только половину модулей портировал)

Код: Выделить всё

procedure GenNoise(a:TArrayReal; amp:Real);
var i:Integer;
begin
for i:=0 to Length(a)-1 do
  begin
  a[i]:=Random*Amp;
  end;
end;

const
  N=1024;
var
 i:Integer;
 a,b,c,d:TArrayReal;
begin
 SetLength(A,N);
 SetLength(B,N);
 SetLength(C,N);
 GenNoise(A,1/(1 shl 8));
 B:=Copy(B,1, N div 2);
 C:=Copy(B, N div 2, N div 2);
 D:=Sub(B,C);
 AddArrayInChart(Chart1,D, mode_Amp_Samples,1);  
 end;

СЛАУ, Рунге-Кутт, численное интегрирование и т.п.

давайте обмениваться что-ли.

[serbod]

Кстати в Лазаре и МСЕ оооочень-оооочень не хватает именно рисования ГУЙ в коде - как это сделано наприклад в ФП-ГУЙ (описание всех ГУЙ-пропертей в одной строке, по типу ТСЛ/ТК)

Одно время я злоупотреблял рисованием гуя в коде. Но потом полностью перешел на использование TFrame, потому что оно не только упрощает визуальный дизайн, но и работает как конструктор визуальных компонентов. Можно свой TFrame добавить на панель инструментов и вставлять как обычный компонент.

Сейчас я использую программное конструирование гуя для LAMW (Android), поскольку там неудобный и недостоверный визуальный редактор, плюс куча нюансов в работе контролов.

Еще была попытка конструировать GUI в QML-стиле, описывая в текстовом файле контролы и их свойства. Пока не догадался, что это ничем не отличается от обычного .lfm, который можно использовать и в райнтайме. =)

[Снег Север]

Pavia, держите

Там кое-что устарело и неактуально, например, работа с комплексными числами, но это небольшая часть модуля.

[V.Pozyvnoy]

Отлично. На free Pascal, моя тестовая процедура сохраненная в отдельном файле вызывается и компилируется с основной программой. Теперь пробовать что бы основная программа под Lasarus использовала процедуры которые отдельно, в файле.
Просто я хочу разнести части визуального программирования от численного программирования.

[debi12345]

Кстати в Лазаре и МСЕ оооочень-оооочень не хватает именно рисования ГУЙ в коде - как это сделано наприклад в ФП-ГУЙ (описание всех ГУЙ-пропертей в одной строке, по типу ТСЛ/ТК)

Типа KOL?

Не знал про оный, сейчас почитал. Да, похоже. Наиболее ярко этот подход выражен в FP/GUI от Грэма. Помню даже пытался уболтать Мартина добавить этот вариант "рисования" GUI-я. RTTI-подход ИМХО слишком хрупкий, трудно выруливаемые проблемы компиляции в RTTI при сменах версий, которые Мартин менял с космической скоростью - из-за этого мне пришлось забросить развитие 2-х серьезных проектов. Также не удалось перенести (опять бесконечные мисмэтчи в пропертях) еще один серьезный проект с Дельфи7 на ДельфиХЕ, поэтому сейчас приходится запускать этот проект в ХРюшной виртуалке.
С тех пор у меня на RTTI-подход стойкая аллергия.

[Vadim]

Наиболее ярко этот подход выражен в FP/GUI от Грэма.

Он, как я понял, больше ориентировался на визуальное конструирование, которое бы в итоге давало чистый код. У наших тоже была подобная разработка, работала хорошо, мне нравилось. Назывался VISG. Там интерфейс проектировался чисто визуально, потом запускался парсер и в результате получали чистый код, причём для нескольких языках программирования. К сожалению, весь интерфейс строился на WinAPI, видимо поэтому проект уже давно издох.
KOL начинался как чистый код построения интерфейса, т.е. одна функция - одно окно, ещё одна функция - кнопка на окне и т.д. Похож на GTK. Намного позже туда добавили визуальную часть, но она успехом уже не пользовалась. Проект тоже издох. На SF и GITHUB лежат исходники, но после 2013 года они не менялись. Можно было бы ими заняться на предмет внедрения кроссплатформенности, но там работа только для win проделана просто громадная, быстро кросс не добавить.

[Снег Север]

Может, потому и не развивается, что никем, практически, не востребовано? Я помню этот KOL - жуткое неудобство проектирования интерфейса совершенно не оправдывает выигрыш в размере исполняемого файла.