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

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

НЕ читами является примерно такое

#pas
function(obj:TMulti)
begin
  ....
  obj.doMethod(да мало ли чего тут);
  ....
end;

Внимание, это не просто левый поинтер, а указатель на конкретный класс, и среда отслеживает, чтобы он таковым являлся. Что значит таковым - при вызове мы имеем право туда подставить и другой класс, но он обязан быть наследником исходного.
Т.е., чтобы это делать необходимо навести порядок с отношениями наследования.
ВСЕНЕПРЕМЕННО
Ну я так и сейчас говорю

Galkov писал(а):

Просто надо один раз договориться о самосогласованном решении, вот и все...

Столь подробно я не стал тогда этого объяснять AlexKir, потому-что не очень рассчитывал на успех (если уж на чистоту), а тебе не стал, потому-что ты это лучше меня знаешь

А теперь давай вспоминай, кажется AlexKir сообщал, что попробовал снять "защиту" с метода ##hselect (или его научил кто - точно не припомню уже...) и радостно сообщал, что все работает (типа - УРА). Одна незадача (с печалью он сообщал) - выходные события происходят на оригинале.
Ну, блин, не стал я его посвящать в искусство подмены EditMultiEx.FParent
Скажем потому, что еще сам не понимал, как правильно (+ вышесказанное)

Ну а теперь у меня с этим есть определенность, и аналоги из "классики"
Давай посмотрим, что есть такое точки в нашем элементе в этой самой "классике"
Левые и нижние - это методы.
Правые и верхние - это виртуальные ф-ии. Причем, если не назначены, значит абстрактные.
А подключение связи, это создание объекта наследника, только с переопределением этих виртуалов такими методами, которые вызывают другие методы других объектов.
В общем, как-то так...
И тут есть маленькая тонкость, приводящая к большим последствиям, как мне кажется
Эти абстрактные виртуалы могут лежать как в private, так и в public
Если мы только наследуем, то нам по барабану, мы можем переопределить любой
А если занимаемся объекто-указанием, то нам доступны только public
Может все это несколько коряво а только по смыслу должно быть верно

Ну скажем есть у нас адаптированный к нам класс TStream - он еще не знает, кто он такой (File или Memory), у него в секции private есть всякие виртуальные методы (Read, Write, Seek, и т.п.) которые будут переопределены конкретными наследниками.
А то, что он к нам адаптирован, означает, что к него есть в секции public абстрактный метод onRead, который переопределится при создании схемы...
Ну и что такое элемент DataToFile
Это оболочка над указателем на этот, адаптированный к нам класс TStream.
Ну, грубо говоря, не видим мы точек из секции private...
И получается, что событие onRead должно возникать на элементе указателе, а события "Read, Write, Seek, и т.п." - на элементе оригинале
Причем, не забудем, что назначаем-то элементу указателю конкретный объект, и вовсе не класса адаптированного TStream, а какого-то из его наследников - MemoryStream, или FileStream. А они отличаются от предка как раз тем, что злополучные точки "Read, Write, Seek, и т.п." у них как раз уже подключены.
И получается, что то, что эти события срабатывают в оригинале - совершенно правильно, так все в "классике" и происходит...

---

Ну ладно, это все слишком умно и непонятно. А может, и не совсем строго
И фиг с ним... Но у нас в HiAsm все эти сложности могут иметь прямую аналогию, которая нам гораздо понятнее, и достигает того же результата

Давайте посмотрим...
Скажем, мы СОЗДАЕМ элемент, используя фичу data_element, опубликованную Dilma
Фактически мы в этом св-ве (пусть, скажем, называется class) установим TMulti, из вышестоящей демки...
Когда устанавливаем, то:

Dilma писал(а):

список имен доступных на схеме элементов, выводится в качестве выпадающего листа в редакторе св-тв

Вот теперь, исходя из всего вышесказанного, такое предложение:
После выбора конкретного элемента (класса TMulti) должен появиться список точек этого элемента с чеками, и пользователю предлагается оптичить необходимые точки (грубо говоря, ну зачем мне все 150 точек от элемента коллеги nesco)
И главный результат: события на тех точках, которые появились на элементе - в оригинал не пойдут, а будут здесь, у нас. А остальные - пойдут именно в оригинал.
Вроде по-понятней и наглядней, чем всякие public/private, а результат тот же самый

Ну и у этого элемента должна точка ##obj, может быть (а может быть и нет...) и одноименное св-во того же типа, но только при установке которого лист следует делать (если делать...) не из классов, а конкретных элементов....
И тут уже - никаких оптичиваний...
Хорошо бы чтобы не просто полный лист элементов, а тех, которые являются наследниками св-ва class
Но возможно, такое навороченное св-во obj - это пижонство...
Вполне можно обойтись верхней точкой ##obj и потоком
Мне так кажется... посмотреть осталось