Уже придумал как можно встроить код-макрос из элемента .
Идея та же что в КОЛ+МСК: "Зеркальная схема "!
Элемент будет работать по двойной схеме.
сначала в дизайнере схем вставляется ложный скрипт
по аналогу VBS но не выполняется сразу
просто вставляется в модуль как данные .
Дальше запушенный модуль генерирует на базе
полученных данных *.inc файл и ВНИМАНИЕ !
создает "зеркальную схему" заменив в ней
псевдо скрипы на рабочие элементы
в которых происходит вызов уже встроенного
в "зеракальный элемент" кода .
ЗЫ
Все это разумеется совершенно лишние изощрения гораздо проще эту идею реализовать как "свойство среды"...
(Вроде "узлов")

Но у меня есть впечатление что я с Вами разговариваю на разных языках .

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

Нельзя рассматривать HiAsm только как компановщик из готовых блоков.
(Простой механизм создания этих блоков все же предполагает их ПОВТОРНОЕ использование НО зачем нужно
создавать такой блок если он нужен только ОДИН раз в конкретной схеме? )

Вы же сами у ходите от чистого "кейс проектирования"включая Парсеры и Скрипты.
Но если для разработчика прикладного ПО скрипты это иногда единственная возможность создания
гибких программных продутом то тут применять ТОЛЬКО срипты и парсеры совсем НЕОБЕЗАТЕЛЬНО!

(Они тут скорее как экзотика, вроде многопоточности )

HiAsm это среда разработки программ.

AlexKir, а чего Вы, вообще-то, хотите
Я, например, уже начинаю терять мысль.

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

Если что-то иное, то это осталось за гранью понимания (моего, по-крайней мере), и требует дальнейшего разъяснения...

Позвольте вклиниться в вашу беседу вместе со своим скромным мнением
Мне не понятно, почему до сих пор идея создания компонент непосредственно в среде, рассматривается как откровенно ламерская. Мол умный человек сможет преодолеть любые трудности ради того, чтобы создать свою компоненту. А все остальные просто ламеры, и пускай они своими корявыми ручками не трожут наш светлый и чистый Хиасм. Давным-давно я пописывал небольшие(5000-10000 сторок) програмки на Турбо Паскале 7.0 под ДОС, и не забыл те "старые добрые" времена, когда не только программирование, но и простейшее администрирование требовало способности к мгновенному переводу в уме чисел между системами исчисления с различными основаниями, а работа в командной строке была будничной для любого неквалифицированного пользователя.
Я не считаю, что создание компонент в настоящий момент, это уж слишком сложный процесс. Но какое это имеет отношение к визуальному программированию? Если мы хотим, чтобы Хиасм шёл в массы, то пусть он будет ближе к этим самым массам, пусть все они и ламеры позорные, криворукие и безмозглые. Однако сейчас этому самому паскалю в школах учат, паршиво, но учат.

P.S. Работа админом научила меня терпимости по отношению к простым пользователям. Иначе бы у меня давно крыша поехала

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

Идея включить компонент-код в программу не нова. Были даже и такие предложения - декомпилировать EXE и составлять по полученному коду схему из hiasm компонент, а все что разбору не поддалось заменять на вот такие вот програмные блоки. Красиво не так ли?

Теперь собственно о компоненте-коде. Делать его так же как скрипты по интерфейсу, но со вставкой непосредственно в код проекта не хочется. А хочется именно вставлять компонент, о чем т-щ Galkov, уже не первый день говорит тут. Да конечно сейчас вставить кусок кода не так сложно, но и сложней чем могло бы быть при условие что кусок этот понадобится всего раз. Поэтому нужно вносить программы для написание компонент в саму среду и делать два принципиально новых типа: статический компонент и динамический. Статический - это то, что хранится на лдиске и то что мы имеем сейчас. Динамический - это компонент существующий в пределах одного проекта и сохраняемый всесте с ним в sha.
С возможностью править конфиг и коды без перезагрузки среды мы автоматом получим всесторонне полный и гибкий механизм для написания своего кода - как для использования в дальнейшем, так и в текущем проекте. Причем в этом случае переход между статическим и динамическим компонент заключается в одном клике мышкой. Чего не скажешь про скриптовую модель.

ДУмаю что это внесет окончательную ясность в ситуацию.

А вот и не рассматриваю я ее как ламерскую. Просто не вижу достойных вариантов. А ламерством считаю НЕ( ) идею выхода в код, а попытку этого выхода, БЕЗ( ) знания (не такого уж и большого) того, чего требует этот выход. Тут есть разница, я думаю......
Логика следующая: Dilma с этого начинал, и пытался сделать самый минимальный переход от компонента визуального программирования к кодам элемента => наворачивались новые и новые фичи, причем не от того, что правой ноге так захотелось => получилось то, чего сегодня есть. В качестве одного из начальных вариантов - элемент VBScipt. Он значительно менее функционален, чем обыкновенный элемент, хотя его проще создать.
Из этого я делаю простой вывод - кавалерийским наскоком (без потери функциональности) сделать проще и понятнее не получится.
Это, безусловно, не догма. Но я внимательно слежу за форумом, и кроме "кавалерийских" наскоков пока ничего не усмотрел. Может и плохо смотрел - давайте обсуждать конкретно, но, зная все-таки, зачем это все сегодня сделано.
Я, например, буду рад более простому выходу на код без потери сегодняшней функциональности. А создание более простого входа в код, но не все позволяющего (типа как в VBScript) - вот это вопрос. Действительно ли технология ЭЛЕМЕНТА настолько сложна, что есть необходимость в этом промежуточном звене
((вот и думаю, что нет))
А фразу про "умного человека" я произносил бы по другому: Не настолько это большие трудности, чтобы быть препятствием для БОЛЕЕ рационального (или гибкого, если хотите) программирования.
Хотя (повторюсь), я ЗА их уменьшение, не во вред функциональности.

Опять же есть возражения
Думаю, что было бы правильным с любого языка высокого уровня иметь выход на более низкий.
Во-первых, не все стандартные возможности языков высокого уровня сегодня реализованы в HiAsm. Вот написал я скажем MatrixWave. Можно ли это было сделать как мультик в HiAsm ? Шелестеть динамическими списками - врядли.....
Во-вторых, это является признанием того, что заложенный в среду ИИ не является настолько высоким, чтобы конкурировать с человеком.

Ну и наконец, мне, например, хотелось бы, чтобы создание СВОЕГО элемента происходило прямо из среды (тот же ECreator и Code) и попадало, например, в раздел Custom, а лежало в папке проекта. Еще хотелось бы, чтобы ECreator.exe и Code.exe сопровождались с каждой версией и не требовали перезапуска HiAsm. Чтобы можно было сделать копию стандартного элемента в раздел Custom и папку проекта.

Другой вопрос - элемент, как схема на HiAsm. Вроде напрямую связано с визуальным программированием. Но это, вроде, уже на подходе, судя по голосованию.......

Просто видимо Вам мешает меня понять "взгляд электронщика".
"Чип можно и заказать, но его внутренности с паяльником
не лезь - это святое!"

НО "элементы схемы" с точки зрения обычного программиста
это ничто иное как вызов подпрограмм и если это
не продукт для конечного пользователя а IDE то
наличие сриптов без наличия возможности непосредственно
делать однократные вставки кода из IDE выглядят ...
Гм Скажем так экстравагантно .


Зы

Кстати генерацией кода из разных самодельных средах
я занимался еще будучи школьником на Кувт 2 Ямха
на Бейсеке в 87 мохнатом году .
Продолжил на Электронике 80 . Искре 1030....
От графического редактора с генерацией текста на Бйсике
до довольно сложных "Дизайнеров" на (и для) Turbo Vision,
SuperVision и OWL в BP7 .
Но потом появился Длефи долгое время его вполне хватало моих нужд
( написания учебных пособий , моделирования и расчетов)
Потом вход пошли скрипты и идеи генерации как-то
отпали....)
Наткнувшись на HiAsm ранней версии я удивился :
"Кто это до сих пор генерацией балуется? "
Но старая версия не чем особенно похвастать
не могла и компилятор от Дельфи и размеры
ЕХЕ-шнков за пол метра...Так что хныкнув, забыл !
Но где-то в начале этого года я дорвался до КОЛ+МСК
и собственные проекты (под два метра сжатых
ЕХЕ-шников) стали казаться анахронизмом.
Кое что удалось перевести в МСК но для новых
проектов нужно было что-то вроде интегратора
разноколиберных модулей с легко изменяемой
конфигурацией .
И вот тут я и наткнулся на 4d-куб на freeware.ru
и понял что HiAsm перебрался на КОЛ !
Но меня ждал еще один сюрприз - FreePascal компилятор !
Сбывалась "мечта идиота" о лицензионной чистоте
и удобстве разработки !
.....
И довольно быстро "накидав" схему интегратора я
задумал перевезти на HiAsm и весь остальной проект
- Мелиоративная ГИС с нейро фильтрами данных. точнее
"Water View System – Интегральная система аналитического
мониторинга водных ресурсов с элементами ГИС."
(Она же Цифрового Исследовательского Стенда (ЦИС)
для моей аспирантуры )


И вот тут то и выяснилось что сделать это гораздо труднее
чем при прежде на МСК. Если там "мясо расчетов" и логика из VCL
просто пережала в аналогичные методы в МСК .
То в НиАсме "среда оделена от четверга" (то бишь код от
Дезайнера схем)..

Так что это, для меня не совсем досужий вопрос...

С уважением к создателям и продолжателям дела HiAsm, Alex

Ну это уже через чур !
(Хотя есть же "невозможный в прнципе " декомилятор Дельфи+VCL
DoDo там "мясо" методов просто заменино на асм вставки )


Я уже писал что вижу НЕСКЛЬКО уровней для разных задачь .
(Ну зачем арифметику то через парсер делать?)
Я бы о сриптах и парсерах подумал бы в самую последнюю
очередь и только для Рунтайма .
Зачем чудовищный избыточный
код тащить в для того чтобы ОДИН раз Y=Sin(x) просчитать ?
Exe-шники некоторых схем вообще до 5кб упадут если
применять "прямой код" .
Вещь первой необходимости, это все-же Код -процедура.

Грубо говоря НиАсм это завод автомат по производству чипов
и схем на их основе - так зачем нужно ставать всюду сложную
программируемую логику если под рукой логика "заказная" ?



Вот именно вместе с ним в sha , но это лучше делать на уровне
не большого кода-процедуры .
А можно ли в НиАсме делать include XYZ.Sha?
Очень было бы удобно было!


Вы УЖЕ сами поняли что чего-то в вашем "суповом наборе"
не хватает и сами добавили скрипты и прасер а также
генератор шаблонов для новых элементов.
Но скрипты в большинстве случаев это просто ЛИШНЫЙ
код в большинстве проектов действительно статического
кода более чем достаточно.

Повторяю если я задумывал ГЕНЕРАТОР кода от
в о ЭМУЛЯТЦИИ (Скрипт-Процессоры и парсеры это ведь просто ЭМУЛЯТОРЫ)
я думал в самый разпоследний "другорядь" !!

Не предлагайте делать схемы на «рассыпухе» и РУ3-РУ5
когда рядом пылится бесплатный цех спец БИС.
Или как вариант всю «заказную логику» эмулировать
на ЭМУЛЯТОРЕ Z80 или I8080 !

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

==========================================


Если правильно Вас понял, основное беспокойство вызывает нерациональность ВСЕХ сегодняшних языков прграммирования, в т.ч. и HiAsm. А вопросы входа в код, удобства или неудобства этой процедуры, рассматриваются Вами (это мое предположение) именно в этом контексте.
Эта обеспокоенность большое уважение вызывает. И оценки в 5К "себестоимости" пустой формы примерно правильны (вообще-то, должно быть по-меньше).
Вот только кажется, что это достижимо ЗНАЧИТЕЛЬНО большими усилиями, чем простенькой доработкой генератора кодов в HiAsm. Давайте называть вещи своими именами: Генератор Кодов - это Компилятор.
И стратегические направления, которые Вы предлагаете, видимо верные. Пример KOL, в моем понимании. демонстрирует полное несоответствие объема ИИ, заложенного в современные компиляторы, требованиям ООП. Поэтому и библиотека написана в "старом" стиле. Есть другие примеры, правда сам не смотрел, говорю со слов Dilma. Там тоже, вроде, НЕ применение ООП дает выигрыш по эффективности.

Теоретически возможна такая постановка вопроса: пусть интерфейс с пользователем будет Крайне-Объектно-Ориентирован, но это не накладывает никаких ограничений на компилятор - он будет генерировать коды по максимально рациональной схеме. Эффективность такого подхода Кладов и доказал делами, а не рассуждениями, как мне кажется.
Вопрос: можно ли ПОЛНОСТЬЮ изменить генератор кодов в HiAsm, сохранив внешний интерфейс Под полным изменением понимаю перехват ВСЕХ функций компилятора по созданию объектно-ориентированного кода. И именно HiAsm, опираясь на схему и коды (или скрипты) элементов оставил только подпрограммы, сам решил где (в динамике или нет) хранить поля объектов как простые данные, заменил лишние функциональные вызовы на inline, и т.д. (все оптимизационные задачи, но в рамках всего проекта). Ну вот тогда и можно получить 1-2К EXE-шник на пустую форму (если и KOL понимать как скрипты элементов и включить его коды в оптимизационную переработку).

Мне представляется, что аналогичная постановка достойна уважения. Одна беда - это не есть простенькая доработка..........

Это не совсем так. Каждый новый человек более менее освоивший HiAsm привносит идеи(не всегда конечно но как правило), которые были заложены еще с момента рождения программы. И моя текущая задача не воротить все подряд, а делать так чтобы эти идеи всплывали сами собой на основе того, что есть тут и сейчас. Как шло развитие программы:
до версии 2.0
- hiasm это просто неудобный графический редактор с 50-70 компонентами, зашитыми в EXE программу сразу. По составленному скрипту(именно скрипту!) нужные точки компонент соединялись и обзазовывали работающий EXE. Собственно больше в hiasm на тот момент ничего не было.
(как видите вставить "компонент-код" теоритичиски не возможно )

до версии 3.0
- вводится понятие контейнера
- вводится понятие переменного кол-ва точек
- наконец(!) появляется возможнсть вставки скриптов на языке VBScript
- рабочее поле расширяется до размера 3000x3000px
- появляется возможность копировать элементы
( очевидно, что вставка компонента опять не возможна в принципе )

и что есть сейчас:
- живой компилятор кода
- полноценный редактор форм
- динамически создаваемые схемы
- поименованные динамические точки в контейнерах
- пользовательские компоненты на основе схем HiAsm
- документирование проектов
- скрипты в самой среде
- 5 типов проектов
- подключение hiasm модулей в виде dll
- рабочее поле расширяется до бесконечности

заметте что произошел наконец переход к компилятору причем сделать это быстро и незаметно удалось путем сохранения ООП модели создаваемой схемы. И вот только теперь возможна вставка кода. И поэтому - то только теперь стали всплывать такие вопросы . Тоже самое было и с самим компилятором тогда, тоже самое сейчас(уже было) с ссылками на элементы. В данный момент медленно подбираемся к быстродействию схем. Это и называется развитием проекта Вы же так ставите вопрос, словно кто-то что-то насильно не хочет делать, упершись рогами и копытами в пол. Просто не нужно форсировать события и тогда в дальнейшем сам собой образуется бонус(те самые статические и динамические компоненты), как это и было со ссылками к примеру: в версии 3.0 правильно была выбрана структура проекта и компонент и сейчас ввод этой ф-ции(очень полезной ф-ции!) оказался тривиальным.


Что это должно означать? Вставка схемы в контейнер? Это умеет делать ViewSHA или ImageMulti(он даже из Интернета вставлять схемы умеет) днако использовать их в проекте нельзя

Создание AntScripta продвигается !

Написал первый макет на Кол+Мск
Обрабатывает схему заменяет вызовы
удаляет скрипты и извлекает из них код и собирает
его в файл..


Но возникли новые траблы в виде необходимости запуска
нескольких разных процедур из одного ярлычка элемента
на схеме - не создавать же в самом деле кучу разных элементов?
- Хотя возможно это выход. Но пока я мои мысли крутятся
возле массива процедур с вызовом по индексу Правда тут возникает
вопрос А что делать с разными параметрами .
Есть еще идея посмотреть как это в VBS элементе устроено!
Возможно все сразу прояснится.

Но это уже в более подходящее время суток !

З привітом, Alex

Так вот в чем дело !
В таком случае поздравляю !
Это действительно прогресс !!!!!!
Очень немногим удалось из тьмы "самопального бейсика"
продвинутся к свету очень необычной ИДЕ- коструктора .
(Даже завидно, сам я дальше идеи об улучшении
качества своего ПО добавлением туда
различных сриптов не продвинулся.)

Я о элементе - указателе на полностью готовую схему .
Например мой калькулятор с небольшой доработкой
может стать готовым дополнением .
(Но зачем мне лишние "танцы с бубном"
или отдельный ЕХЕ? Да и “микро-схемы”
лучше отлаживать в ”Гордом одинчестве ”
а не в разбухшем проекте ! )

Я предлагаю просто тот же контейнер но без
объединения схемы в один файл но так чтобы
ЕХЕ-шник был в результате один.
(Думаю можно дстаточно просто переделать дочерное окно )

Это разумеется мелочь, но согласитесь, удобно !
ЗЫ
Да , еще одна мз тысячи мелочей: почему в дизайнере
ФОРМ нельзя "батоны" по Сtrl + стрелки двигать ?
Мышкой далеко не всегда удобно

AlexKir, вы когда спите если не секрет?


Языками(скриптовыми по большей части) я занимаюсь давно уже и "самопальный Basic" сам по себе никогда не реализовывал. Каждый из языков был прикручен к конкретной задачи:
Язык Delema(почти С в чистом виде) оперировал объектами-графиками и позволял на ряду со стандартными возможностыми быстро и наглядно считать, выводить и формировать мат. формулы.
Следущий скриптовой язык типа ASM управлял точками на экране в засимости от текущего кадра анимации, а так же создавал или удалял их. Затем был чистый С без модификаций для управления сигналами в узлах заданноой схемы. Фактически это модель движения автомобилей например а узлы - светофоры.
Затем был BootPascal язык типа Pascal со своими расширениями для написаний программ, не требующих ОС для своей работы(загрузчики, вирусы, системные утилиты и даже простые ОС). Он (как Hiasm сейчас) использовал компилятор fasm и на выходе давал автономные com приложения(дамповые программы ныне нигде не используемые уже). Этот проект я так же собирался развивать(все таки аналогов нет), но АСМ не дает такой свободы действий как любые ЯВУ...
Так что hiasm как видите это далеко не паленый Basic . Это всего лишь продукт, который должен был стать четвертым в списке и не более. Идей и работы еще много - потенциал все таки хороший получился. В качестве более перспективного будущего я хочу объединить идею третьего проекта(BootPascal) и идею HiAsm и получить совершенно интереснейшее сочетание - визуальный конструктор ОС. Причем никаких принципиальных проблемм нет раз удалось на 100% переложить эту задачу в язык высокого уровня.


Это из раздела - пользовательские компоненты будет.


С переделки формы пропало. Будет добавлено.

Такого еще не слыхал, хм


Интересно посмотреть, но кажеться ОС написанная посредством ЯВУ будет здорово терять в скорости и как следствие востребована будет в узком кругу

S_E_A,

Встречный вопрос: реальноли написать на АСМ скажем приложение типа HiAsm? Думаю ответ очевиден Вот именно это и называется свободой действий и творческой мысли.


Не кажется, а именно будет, но ведь это в жизни совсем не главное

Вручную проблематично, но имея среду наподобие Hiasm и набор продуманных компонентов написанных на АСМ почему бы и нет



А зачем тогда это нужно, писать еще какую нибудь ОС чтобы потом задвинуть ее куда подальше с глаз долой ?