С тем же CodeGen (по EID результата) это несколько нереально

Ибо "...материализация духа - есть сложнейшая задача научной магии"

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

Ага, это уже писалось (и читалось, естественно).
И именно так я и понимаю разницу между EID и NUM
EID - это то, что получено из sha-файла, и возможно было когда-то и адресом в памяти, но не обязательно, что сейчас.
А NUM, как мне кажется, это то, чего мы получаем по sdkGetElement (не не elGetEID) и является локализацией в памяти в настоящий момент

Что собственно подтверждается наблюдениями за этими параметрами при разных условиях открытия одной и той же схемы
Первый раз:

И второй:


А пока экспериментальным фактом является то, что в b160 подсовывать NUM в поле ID для THI_Event - нельзя. Что совершенно естественно - при EID таки работает, а это не одно и то же...


И вот отсюда предложение: давай изложим перспективный протокол обмена скажем на уровне WriteFile/ReadFile
Прямо здесь.
Будем считать, что написанное сегодня в Debug.pas известно и понятно.
Ну скажем, давай зарезервируем команду F4 (Go to cursor - в нашем случае до выбранного элемента)

Реализация - дело техники.
Тем более, что мне кажется удалось выкинуть из Debug.pas дублирование определений типа _hi_On_Event

Думаю это сложно реализовать (раз не было изначально).
А пока сделать подсветку всех линков(одного потока) и в Дебуге сделать надпись с
именем мультика(взять из комментария) что бы было видно откуда берутся данные для конкретной строки.
типа
[ имя родителя ] [ имя компонента(отправителя) ] [данные] [тип данных] и т.д.
где имя родителя и есть, или имя формы или имя мультика.

Схема со ссылочными контейнерами работает верно как в случае NUM так и EID. В последнем коммите постовил NUM(для работы очевидно нужна последняя версия среды)