А она тебе нужна ?

А мне кажется, что девизом нашего сайта нужно применить или
------------ Дoбавленo в 10.38:
Очень даже полновесное "Hello world !" (на PureBasic это же 3,072 байт. Почувствуй разницу Не дурак же придумал: Краткость-сестра таланта)

Мне -- нет. Скоро и сайт придется делить на Линуксоидов и Виндузятников

nesco, тут вопрос не в быстроте перевода, а в быстроте исполнения программы и оптимальности кода. Поэтому гораздо более перспективно использовать RTCG (FTCG), но тут срабатывает правило 20% - 80%
------------ Дoбавленo в 20.38:

И мне тоже она пока что не нужна.

Думаю, это произойдет нескоро, поэтому продолжаем спокойно жить

Assasin,Переделывать надо CodeGen. ИМХО

Вот как раз результатом такой переделки и родился FTCG (а за ним и RTCG)

Я это прекрасно знаю, как и то, что до сих пор подавляющее большинство использует старый пакет и многих он устраивает.
------------ Дoбавленo в 21.43:

Не поможет, принцип построения связей и передача данных между элементами никуда не денешь. А он построен на медленных метоах упаковки/распаковки данных в структуру TData, и каждый элемент получается отдельным классом, а не непрерывным методом. Но структура построения элементов на FTCG мне, к примеру, до сих пор не до конца понятна, но не дается мне этот скриптовый язык, хотя, он не такой и сложный на первый взгляд. И создать что-то подобное MT_StrTbl сейчас, я не смогу, мне совершенно непонятно, как это сделать. Вот почему я и сказал, что мне проще попытаться прикрутить новый KOL к старому пакету, чем писать новые компоненты на скриптовой технологии FTCG.

Весь паскалевский код и не нужно переносить в сам элемент.
Пишется обычный паскалевский юнит с нужным классом, а в hws скрипте только назначаются свойства и присваиваются события.

вот мне и кажется (упрощенно), что CodeGen должен определять нужно упаковыватьраспаковывать данные в структуру TData или нет. Пусть за два-три-10 проходов, но в результате должен появиться код, равноценный коду от FTCG.

Так вот как раз весь класс ListViewer-a описан в KOL, а сам компонент есть шелл над этим классом. Этот шелл и придется переводить в скрипт, а основной класс писать самому.
------------ Дoбавленo в 22.38:

Осталось только разобраться с кодогенератором и написать новый. Не хочешь взяться

ListViewer в KOL есть класс наследованный от TControl, который в свою очередь наследован от TObj, если не путаю.
Так же и в LCL - TListView -> TWinControl -> TControl -> ...
Так вот... создаем в нашем новом юните класс наследник (обертку над) TListView, а вскрипте только указываем какие его свойства будут использоваться и с какими параметрами.

Wolfik, а как насчёт IC?, из выше сказанного я понял что IC к hws скрипту не прицепишь.

пока всё очень смутно .

Все там прицепляется, еще проще чем в пакете Windows.

Ну очень простое программирование, проще не придумаешь -- создать класс по образу существующего коммпонента, а над ним еще одну скриптовую оболочку по управлению собственным классом.
Одно дело создать скриптовую облочку над существующим классом, и совсем другое дело создать свой собственный класс, отладить его где-то (мне не совсем понятно, где его отлаживать), и его еще потом обернуть скриптовой оболочкой.
Wolfik, сколько ты потратил усилий, что бы понять, как это все взаимодействует
Честно сказать, в скрипте там черт ногу сломает. Как ты умудряешься писать скрипт и видеть сквозь него код целевого языка
Меня, к примеру, очень сильно напрягает, что я не вижу полностью целевого кода. Это сильно напоминает мне разговор на Армянско-Русском диалекте, где перемешаны оба языка, откуда теряется представление о всей фразе целиком
------------ Дoбавленo в 23.23:
Хорошо, понятно с пакетом Pascal для кроссплатформенности -- его надо будет доделывать. Ну а что будем делать со старым пакетом, мне кажется, что еще не скоро новый пакет обрастет достаточным мясом для написания полноценных приложений Да и наработки у народа есть по старому пакету, похерить их что ли придется, не правильно это, как-то. Tad, высказался про то, что ему не понравился размер прог на новом пакете. Я с ним частично согласен. Если чел не хочет переходить на другую ось, то нафиг ему не впала кроссплатформенность и то, что написано на KOL, вполне сойдет, да и размер устраивает

Поначалу тоже путался, спрашивал если что-то было не понятно.
Код можно смотреть и в результирующей программе по Ctrl+D.

На самом деле одно и тоже. Твой MT_StrTbl наследник от THIWin, который в свою очередь наследник еще кого-то...
Так и тут. Я для примера написал TListView. Можно и без наследования обходиться. Разницы нет.
А насчет отлаживать... а свои компаненты ты где отлаживаешь? Так же и тут. Что мешает их из HiAsm отлаживать?
Вот для примера тебе твой LedNumber, переделанный под FTCG. Он правда под Kol, так что в этом пакете без некоторых правок не заработает, но как пример сойдет.
Адаптировать под LCL труда не составит.