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

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

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

мне представляется такая картина: имеет некий базовый элемент, пусть та же таблица. можно использовать ее отдельные точки doAdd, doDelete, doReplace и тд. а можно подключить ArrayRW и этиже действия производить в другой части схемы, хоть во вложенном мультике, при этом вытащив из него только 1 линию, вместо нескольких для отдельных действий. при необходимости использования MT-потоков берем некий воображаемый элемент, который разгружает основной элемент визуально, общается с ним по гипотетической шине данных (1 соединительная линия).

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

вот что-то вроде этого все время витает в голове, когда в очередной раз сажусь за HiAsm.

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

HikeR, "интерфейсная шина" - это хорошо, но теряется наглядность. Вообще-то упаковка всего в мультики существенно облегчает жизнь --- особенно если не лениться и давать мультику и точкам "говорящие" имена. А вообще, есть в Upload такой компонент - Cable. Он позволяет удобным образом протянуть на большое расстояние кучу связей (а для наглядности - поменяй цвет линии: зря чтоли Дилма такую возможность добавил?!)

iarspider, я тебе один умный вещь скажу...

Мы НЕ УМЕЕМ делать интерфейсные связки типа IntegerArray-ArrayRW, MemoryStream-ReadData, и т.п. - на HiAsm
А это есть очень плохо
И не в моей компетенции

Имею примеры своих схем: некий мультиэлемент занимается каким-то низкоуровневым обменом с железом.
Весит это, скажем, элементов под 100-200...
Внешние точки мультика - это методы уже высокого уровня, через них основная схема и работает
Вот и тянутся "жгуты" по всей схеме - в 3-5 линий

Конечно, я умею экономить, использовать MT, и элементом EventFromData владею (для вариантного приема данных)
Но все равно, выглядит - кривовато, типа правой ногой левое ухо

И напоминает использование ПЕРВЫХ вариантов элементов типа ArrayControl...
Там мы очень быстро поняли что это кривовато, и перешли на сегодняшнюю технику массивов, стримов, и т.п..
Что в модели "паровозиков" мы называли "перевозкой ПДУ"
Теперь надо бы предоставить такую же возможность не только в терминах целевого языка, но и схемно

---

Есть у меня и на эту тему соображения... Если бы они нужны кому были

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

HikeR, я бы в твоей схеме, глядя по рисунку, половину бы выкинул и упростил. ИМХО

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

ммм... так не надо выносить эти элемениы, пусть живут вместе, в коде. а на схеме выглядят как несколько отдельных элементов, соединенных парой линий. или такое пока нереализуемо?

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

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

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

Может и ДА...
Даже - скорее всего

Мне представляется, что это некий Handle (кстати эта точка-то есть, и ее назначение именно такое)
Который ОДИН (а не целый жгут) подходит к разным "элементам управления"
В полной аналогии со стримами, битмапами, и прочей нечистью (которая по-научному называется объектными типами)

А что такое "элемент управления"
Да тот же самый элемент (или его "предок"), только открытыми оставлены совершенно конкретные точки + верхняя точка типа ##object
Причем, в отличии от имеющегося сегодня "линка", это должен быть именно линк на объект с его родными св-ми, а не новый экземпляр объекта (что сегодня именно так) с возможно иными св-ами (что сегодня совершенно не так)
Грубо говоря, то, чего есть сегодня про линк - перевернуто с ног на голову

---

Да, я могу сегодня написать IC-"элемент управления" для конкретного мультика, который потребляет уже имеющуюся в мультике точку ##handle
И при интерфейсных изменениях в мультике, все время ловко корректировать этот (эти !!!) IC
Но это же криво, блин...