Спасибо, те если клавиатура терпит насилие, то лучше так как сделал, со свойствами?

в принципе, если эти классы просто набор данных, то можно их вообще перенести в сам поток, который будет сам создавать и разрушать их.
а в идеале вообще должен быть некий объект, ответственный за расчеты и все классы-наборы данных управляются этим объектом.
далее ты этот объект уже передается при надобности в поток, чтобы сделать расчет асинхронно, либо используется как есть для синхронного расчета.

еще раз повторюсь - не могу сказать про fpc, но в делфи создать поле или свойство замкнутое на поле практически равнозначно. разница в десяток нажатий, а то и меньше

А есть директива для публичного/приватного класса? Или имеется ввиду что то другое?

под непубличными я имел ввиду вложенные классы (Nested classes)
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Nested_Type_Declarations

также. фпц копирует делфи, вариативно, местами делают лучше, местами хуже.

Понятно, спасибо!

👌

Пока этим объектом я планировал кнопку (магическую :)).

вдобавок сюда же идут классы, объявленные в секции implementation

уже много раз писали, но я повторюсь - в твоих расчетах не должно быть никаких кнопок, эдитов и тд.
класс расчета должен быть черным ящиком, которые получает на вход данные и отдает другие данные на выходе.
причем этот объект должен быть таким, что ты его с легкостью может использовать в GUI приложение, в консольке, UnitTest и тд

Тут как выше сказали правильно нельзя очищать объект. Ты же его передал потоку. Если поток этот объект обрабатывается, то пусть он там и создается и очищается. По сути ты поток запустил и передал объект и сразу же вслед за этим уничтожаешь. А поток то еще работает. Он же как начинает параллельно основному потоку "течь"

Так что там в Execute тебе нужно очистить объекты. Ну и вообще это правило хорошего тона. Очищать объект на том же уровне, где и его и создавал. Лучше даже в той же самой процедуре и зоне видимости

не знал что так можно :)

более того, ты можешь объявить тип или переменную не только сразу после implementation, в любом месте ниже. можно между методами.
но это скорее из серии вредных советов 🙂

TObject можно не указывать. Он базовый для всех классов

Спасибо.

Спасибо, то есть идея состоит в том чтобы создать некий Контролер (видимо это класс), который будет создаваться событием (к примеру нажатием все той же кнопки) и контролировать загрузку данных из гуи, запуск потока и вывод результата в гуи?

почти.
пусть это будет "контроллер"
его кто-то создает, потом заполняет данными из ГУИ, настраивает каллбеки.
затем контроллер передается потоку на выполнение расчетов, либо расчеты выполняются в основном потоке.
по окончанию расчетов дергаются каллбеки, передающие результаты расчетов в аргументах, либо сам контроллер, если итоговые данные хранятся в нем же.
за разрушение контроллера отвечает либо поток в первом случае, либо вызывающий код во втором.

в новой json-библиотеке, которая поставляется искаропки, начиная с 10.1 выдумали сделать так, что свойство index у массивов начинается с -1 (минус один), а не с 0.
http://docwiki.embarcadero.com/Libraries/Sydney/en/System.JSON.Builders.TJSONIterator.Index
а если это итерация по объектам джесона, то там индекс начинается с нуля.
это что за извращение?