Wolfik, но MT_StrTbl построен на MT-технологии, которой еще нет в новом пакете или уже есть Кстати, а она бы очень не помешала

Так ведь прибивать его никто не предлагает? Есть он и есть. Кто хочет - пользуется.
Про MT - я только слышал Сам ей не пользовался и на старом пакете. Что она из себя представляет?

Цепь структур TData, где в поле ldata каждой структуры прописан указатель на следующую

Ясно. А идеологическая цель создания технологии какая? В каком месте после ее внедрения стало легко и хорошо?

Да я не про прибивать, а про перевод под новый KOL (3.14) и новый FPC
------------ Дoбавленo в 00.34:

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

Все-таки цель не очень ясна. Рискну предположить что это делалось ради того, чтобы элемент принимал кучу своих свойств на одну точку, распаковывал их и устанавливал себя? Короче ради уменьшения линей связи между элементом и к нему направленными данными? Или для чего то другого?

Ну, распаковкой это назвать никак нельзя, вот последовательное чтение, это да. Да и необязательно это должны быть свойства, это могут быть и текущие данные. Проще же передать указатель в функции на один элемен цепи, чем все указатели на элементы или значения передавать в качестве параметров
------------ Дoбавленo в 00.46:
Подобное часто можно втретить в ситемных API, когда в функцию передается указатель на некую структура, которая содержит в себе кучу других структур или указателей на другие структуры
------------ Дoбавленo в 00.50:
Но вот кто ее, с легкой руки, назвал MT (Multi Thread) я так и не понял, ее надо было назвать что-то типа Chain технология

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

Согласен, жутковато. ИМХО, надо копать в сторону цепочной структуры. Но дело в том, что структура TData универсальная, она в себе может содержать все, что нам надо, и простые типы данных, и указатели, и индексы самих типов, по которым и определяется, что мы передаем. Хотя, может это и лишнее будет, тут посоветоваться бы неплохо с Автором пректа

Assasin, Вопрос на засыпку:
Строка до 255 знаков. Есть схема:
code_23475.txt

Результат компиляции:
code_23476.txt
1. Почему не работает ?
2. Откуда взялось Len1 ?

P.S. В IC, даже не используя фирменый Length(), этот вопрос решается простым n:=s[0];

Ошибка в коде компонента: разработчиком компонента не предусмотрена возможность подключения точки результата к выходу из контейнера


А где же должен еще храниться результат вычисления длины строки? Только в зарезервированной для этой цели переменной с уникальным именем. У нас тут не компилятор, а интерпретатор, который ну никак не может анализировать код на возможность оптимизаций, к тому же у нас остается привязка к интерфейсу обмена данных между обычными компонентами и структуре TData.

Да на здоровье, можешь хоть каким образом вычислять длину строки, FTCG тебя не ограничивает в вставляемой в целевой код в строке
------------ Дoбавленo в 12.17:
Wolfik,
Сколько я ни искал, где у тебя объявляется переменная ctrl, нигде не нашел

А где скачать сие пакет?

http://narod.ru/disk/10792398001/Pascal001.7z.html

Пришла идея кодогенератор сделать, а весь Lazarus на моей скорости не скачать
------------ Дoбавленo в 13.24:
Пришла идея кодогенератор сделать, а весь Lazarus на моей скорости не скачать

Немного обновленный пакет