Мне он тоже больше нравится

да видимо стоит добавить новый параметр в конфиг, который будет определять dll-ку для отображения внешнего вида элемента.

второй вариант очень похож на инкарнацию HubEx (если можно так выразиться), теоретически возможна путаница (хотя не уверен), посему - быть может вхождения в кабель сделать под непрямым углом, а 45 (135) градусей?

Dilma, я бы предложил сделать связь между точками Cable толще, скажем 3 пикселя. Это вполне логично - провод тонкий, пучек проводов толстый.

Абсолютно согласен. Я сам не пойму почему сравнивают эти технологии. Существующая реализация достаточно неэффективна. У меня есть предложение добавить в кодогенератор возможность обрабатывать схемы в которых, одновременно, будут использоваться два вида элементов, стандартные .pas и скриптовые .hws тогда можно будет переложить на скрипт всю работу Cable и исключить генерацию кода, т.е. "генерировать прямые линки". Примеры такого подхода я прикреплял выше.
Отладчик, думаю, не сложно будет доработать чтобы он понимал тип данных data_cable и отображал помимо данных номер/имя провода в котором произошло событие

nesco, элементов всего восемь, и сделано это было из за ограничений среды. Два года прошло все таки. Вот здесть http://hiasm.1gb.ru/xf/topic.php?t=9708&start=0 , в 5 топике я писал про свойство Rotate и Dilma в 7-м пишет - "Интересная мысль. Думаю имеет смысл это сделать"
Вот только я не знаю реализовано ли это сейчас.

[size=-2]------ Добавлено в 03:14
или вот еще, смотрится по моему неплохо.

это исключено.


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

Подобие на кабель, только полностью из MT-потоков, в компонент сувать не стал, но так скорость у кабеля выше, чем у MT:
code_14632.txt

Если в MT_ChanelToIndex не заниматься "динамическими плясками с бубном", то должно быть быстрее, чем Cable
Жизнь, она обычно по-проще устроена......

А если кому надо, в компонент перевёл, пример внутри. MT_VarToIndex, MT_IndexToVar

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

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

Все это Чешко уже сделал, и, как мне кажется - более профессионально. Нет, не в элементах из этого топика, а по ссылке, которую он привел выше.
Там как раз использована MT-технология, и как раз без "динамических плясок с бубном" (потому и быстрее)
Сам это не сразу понял - прости меня, Чешко

Грубо говоря, замени у него data_cable на data_integer - и получатся MT-элементы общего назначения. Два "горизонтальных" с успехом заменят сегодняшние MT_ChanelToIndex и MT_IndexToChanel.
А "вертикальные" - то, что ты выложил, но будут быстрее работать

Тогда надо все-таки добавить вкладку "Кабеля" с ее компонентами в пакет, но оставить старые i>ch ch>i для совместимости, лично я согласен с этим, и вид мне тоже больше второй по душе(По Dilma пост с картинками кабеля), все же лучше, когда программа работает быстрее, чем делать то же самое но медленнее.

Я это видел и читал давно.
Вопрос был к Assasin, что он имел ввиду про форму элемента и говоря, что

Гы, гы. Осталось в *.ini компонента прописать вершины полигонов, а в среду поддержку, и рисоваться будет, все что душе угодно.

Tad, это значит добавить в среду поддержку "сторонних" форм компонента(треугольник, цилиндр, что душе угодно!), из dll(но как их делать уже проблема) или, как предложил nesco в ini компонента прописать полигоны а в среду поддержку

Вот я и говорю : Например ?

я бы тоже не отказался на этот пример посмотреть