Хотелось бы, иметь точку выборки - дата-Index, для выборки переключения линий событий в одну.

В MT_IndexToChanel и IndexToChanel она есть а в MT_ChanelToIndex и ChanelToIndex отсутствует.

1) с пакетом ошибочка не вышла ли?
2) верхняя точка Index для элементов MT_ChanelToIndex и ChanelToIndex сделает их не тем, для чего они изначально были нужны. Следовательно стоит пересмотреть средства реализации своей задачи.

Два похожих элемент и практически одинаковой конфигурации почему бы не сделать одинаково?

отношу это к теме РЕЛЕ. так как они останутся теми но будут иметьб дополнительное управление, только и всего.

это не так. Элемент ChanelToIndex по своей физической сути является элементом среды и в пакетах FTCG не генерит ни байта кода.
То, что вы предлагаете реализуется на элементе dodata в связке с одним из хабов
code_14597.txt
поэтому предложенная модификация бессмыслена.

Вы не поняли сути:

Точка 'индекс'-дата будет переключать поток событий с данными, а не замещать данные в них. Именно это делают элементы MT_IndexToChanel и IndexToChanel, нотолько с одного на многие.

Пример схемы - подобие.RAR в файлообменнике.

Sergoo, после этого поста я вообще перестал понимать что-либо. Мы говорим о каких элементах - семества IndexToChanel или ChanelToIndex Если о последнем, то что там подразумевается под переключением потоков событий

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

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

1. Ты правильно меня понял. Я уже писал о принципах комуникатора типа реле и шагового устройства и повторять небуду. принцип сам посебе важен - один повыбору на один из N-выходов или N-входов по выбору на один выход.

2. К сожелению Hiasm обладает некоторым ограничение на создание схем, где мого раз повторяются почти одинаковые схемы(на 40% совпадений). Я уже сталкивался с этим. Обход через DLL не целесообразен по замыслу программы.

пример ограничения?

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

Вот и приходится из трех делать одну - это касается радиокнопок и флажков. Количество строк в таблицах в списках везде одинакова >20.000 тысь.

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

Только при использовании одного контейнера происходит экономия и Элементо-емкости и за одно упрощает схему.

Используя ваши подсказки удалось снизить количество элементов почти на 1/4 и тем самым увеличить скорость на 5 процентов.

добавление одной точки сэкономит 20% Строк програмы в целом.