А почему, после появления преимуществ FTCG разработчики не переводят на него весь стандартный пакет?
Просто некому и некогда? Или потому, что убавится количество внешних разработчиков у пакета?

Потому что на стандартном способе кодогенерации намного проще писать компоненты, и если не ошибаюсь, то на FTCG не преобразует типы.

Основных разработчиков у пакета Windows на сегодняшний момент трое, из них один совсем молодой, ЕМНИП. И только один из них в совершенстве знает FTCG -- сам Автор. А мне, вместо того, что бы изучать скриптовый язык FTCG, на порядок проще нарезать IC, а еще лучше, если это будет контрол или системная утилита на WinAPI.

Кстати, login, а ты знаешь что такое "изучать" чужой ЯВУ, мало похожий на Delphi
------------ Дoбавленo в 14.32:

Там еще и Hub не работает. Такое впечетление, что он не совсем подходит для основного пакета, только для мелких задач.

login, еще что хотел сказать. Если нормально выучить основное схемопостроение и научиться искать наикратчайшие алгоритмы, то и в основном пакете можно получить неплохие результаты. А уж какие ты разрабатываешь алгоритмы, мы все уже видели на примере схемы из топика про локальные переменные.

[offtop]Я хорошо знаю то, что "уже знаю", и, даже, неплохо, совершенствую это..
Но изучить что-то, абсолютно, новое, почему-то - пытка, и стрес.
Из умного, превращаюсь в умственно отсталого. nesco, всеравно, Вам проще. А мне надо учить Delphi, и потом, учить скрипт, который печатает ето делфи на листочек монолитным кодом. 100 годков думаю мне хватит. [/offtop]
------------ Дoбавленo в 14.39:
Никуда я от Вас не денусь - изучу. С Вашей помощью, темболее..

Если ты выучишь Delphi, то нафиг тебе не нужен будет скриптовый язык FTCG, все можно будет делать в IC блоками и намного проще, чем из компонентов FTCG лепить, и быстродействие будет выше.
И не переведешь ты все на FTCG, интерфейс не позволяет

nesco, ну вот так, кажется, понятно, почему не переводите пакет. [offtop]В далеком будущем, всеравно надеюсь на развитие FTCG пакета.[/offtop]

преобразует


работает


подходит


кодогенерация на базе пакета схожего с Windows и пакета FTCG имеет свои плюсы и недостатки там и там. Рассмотрение их обоих с точки зрения "а что круче?" ни к чему не приведет.

А ведь не работал, ты сам писал, что не до конца еще доделано. Вот сейчас навскидку не найду эту тему, но точно было, что я тебя про hub спрашивал и пример приводил, где он не работает. Хорошо, где пример, что он работает во всех случаях

Да, и интерфейсные элементы на нем написать можно, покажи хоть один пример

пакет Windows -- пример кодогенератор напрямую работющего с целевым ЯВУ, FTCG кодогенератор, это пример генератора работающего со своим скриптовым языком, который является надстройкой над каким-то ЯВУ, от этого проще не стало, но позволяет работать с любыми целевыми языками

nesco, как это Hub может не работать, если его код не зависит от целевого языка пакета


http://forum.hiasm.com/forum.html?q=3&t=55887 - на скриншоте не уличная магия, а результаты работы FTCG пакета

Мы разговор вели о переводе пакета Windows на FTCG. Можно ли перевести все контролы на FTCG с поддержкой всего функционала, включая менеджеры
------------ Дoбавленo в 15.23:

Хорошо подсказал, наверное, я не тот hub впихивал, действительно работает, извиняюсь
------------ Дoбавленo в 15.24:
Да, кстати, а можно ли сделать FTCG бокс с поддержкой визуальных элементов по типу Панели

99% кодогенератора FTCG не зависит от целевого языка и не имеет смысл рассматривать его возможности в рамках одного конкретного пакета (точнее все то, что можно в одном пакете можно сделать и во всех остальных - конкретика в данном случае ничего не меняет)


nesco, если уж не интересны никакие пакеты, кроме Windows, то хотя бы поверхностное ознакомление с ними уж точно не повредило бы. Во всяком случае не тратили бы время на беспредметные вопросы.


FTCG бокс - это что еще такое?

FTCG_Tools -- бокс, контейнер, неужели есть разница

Ткни на что посмотреть, где реализован весь функционал основного пакета "Windows", я с радостью посмотрю

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

между "боксом" и "контейнером" наверно нет. А вот понятия "FTCG контейнер" как такового нет, ибо среда ничего не знает про кодогенераторы и уж тем более их названия.


надо ли это понимать так, что от утверждения "FTCG не умеет работать с интерфейсными элементами" мы перешли к вопросу о том, где скачать полный аналог пакета Windows? Т.е. несостоятельность первого можно считать доказанной?


более менее приемлемая скорость компиляции только у продуктов от Microsoft, пакеты для которых врят ли кто-то когда-то будет делать.


полагаю очевидно, что собирать оптимальный проект из элементов не возможно без посредника в виде некоторого скриптового языка? Это значит, что альтернативой может быть только случай, когда целевой язык и язык скрипта совпадают. Уместность такого подхода в случае, к примеру, Assembler-a (или CSS, HTML, Prolog и т.д.) вызывает очень большие сомнения.

nesco, я уже не раз говорил о том, что FTCG не обязывает писать элементы ручками в своем собственном диалекте. Опять таки же не желание потратить пол часа на ознакомление с пакетом или хотя бы заполнить пробелы в знании четко поставленными вопросами приводит к формированию ложных представлений о технологии. В том же пакете QT есть примеры элементов (визуализаторы звукового потока скажем), которые выполнены в виде отдельных cpp юнитов (как в стандартном пакете hiasm4), и подключаются через относительно простой hws скрипт, который при желании можно генерировать автоматиматически по INI файлу.

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

Я про такое и не говорил, а то, что я сказал относится больше к переводу стандартного пакета под FTCG, нежели о всем FTCG

Для меня это проблема, на данный момент времени, и для меня они ненадуманные

nesco, не надуманная проблема это проблема скорости работы приложений, вышедших из-под кодогенератора стандартного пакета, ибо решить ее в рамках подхода не возможно. "Проблема изучения скрипта FTCG" надуманная как минимум по двух причинам:
1) его изучение вообще не требуется при наличии инструментов, обозначенных по теме выше (требуется лишь составление классов в несколько другом формате)
2) его изучение не сложнее, чем узучение basic, который преподают в школе

ну и наконец:

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