Подумал, как можно сделать сегодня так называемую pointer-ссылку на элемент. Вот что получилось:

с точки зрения среды сознание ссылки это операция эквивалентная нынешней команде "Копировать ссылку", но со следующими поправками - все точки элемента-ссылки переходят в состояние "Не видимый" (т.е. переносятся на вкладку Точки в панели свойств)
- pointer-ссылку возможно создать только в текущем или ниже стоящем по иерархии контейнере

с точки зрения кода Пакет Windows
- для pointer-элемента не создается нового объекта, а присваивается указатель на родительский.

пакет на базе FTCG
- в случае простого элемента(Math, For, If_Else и т.д.) ничего в коде не меняется
- в случае объектного элемента(Buttom, Edit, Label и т.д.) внутренний _id_ меняется на _id_ родителя

имея такую архитеркуту, работа в схеме с pointer-ссылками будет выглядеть например так:
- ставим элемент StrList
- делаем с него голую pointer-ссылку
- отмечаем в точках doLoad, FileName, onLoad
- получаем этакий элемент менеджер, который выполняет тольку одну задачу - сохраняет список в указанный файл.

Соответственно таких pointer-ссылок может быть сколько угодно с любым набором точек, необходимых разработчику в данном куске схемы.

Теперь о проблемах
1) Интерфейсная проблема - очевидно, что у pointer-элементов будут такие же иконки, как и у родителей, на которые они ссылылаются. Поэтому при наличии произвольного набора точек понять визуально чего делает каждый конкретный элемент не возможно.
2) Проблема кода стандартного пакета - если с точками Work и Var вроде все ясно, то Event и Data точки для каждого pointer-элемента сделать своими не возможно. Возможно подключать либо только родительские, либо с наибольшим Z-Order (в FTCG такой проблемы нет, есть только небольшая сложность с event точками, но решаемая)

Предлагаю высказать свое видение решения вопроса(или возможно его исходной постановки) о pointer-элементах.

На мой взгляд FTCG более перспективная технология развития HiAsm. Поэтому предлагаю "обкатать" новый элемент на его основе, не трогая пока пакет Windows.

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

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

Ага, а Delphi2, на технологии FTCG благополучно грохнули на SVN. И на чем эту технологию смотреть, на VBS или на тормознутом QT. Ну, я не знаю, вам видней

1. Добавить какой-либо знак, типа как у ярлыка в винде. При выборе pointer-а подсвечивать связь с реальным, как у менеджеров (в пределах одного контейнера).
2. Сделать системный объект, который будет хранить список обработчиков событий, т.е. элемент вместо прямого вызова события будет вызывать событие у этого объекта, а он, в свою очередь вызовет обработчики из списка. Нужно только изменить кодогенератор, чтобы он подставлял этот "прокси" реальному элементу и генерил инициализацию этого объекта. Как сделать инициализацию - это уже техническая проблема (в связи с тем, что pointer-ы возможно будут в разных мультиках). Например, все "прокси" родительского контейнера должны быть видны из внутреннего контейнера с тем же именем (уникальным для каждого прокси), т.е. сгенерить property с тем-же именем.

tsdima, это ты чего, предлагаешь сделать двойную очередь событий -- виртуальную и реальную, или я чего-то недопонял

nesco, вот есть у тебя, например, кнопка, а обработать ты её захотел где-то в внутреннем контейнере (т.к. схема большая ты разделил её на контейнеры). Сделаешь ты pointer, поместишь его во внутренний контейнер, и пожелаешь, чтобы onClick возникал именно там, так? И никто не запретит тебе разместить pointer и в других контейнерах, и ты захочешь, чтобы onClick возникал везде, где тебе надо.

А что мне нравится, здорово получится, хихи, куча элементов интерфейса и голые(т.е без методов, событий...) мультики Красота! тогда и меньше проблем со стандартами построения схем будет.

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

tsdima,
1. да, как-то так и должно быть
2. с событиями действительно можно так сделать - всего-то и надо добавить эмулятор хаба при генерации кода. Но с data точками такое прокатить не может - данные должны считываться только с одного конкретного экземпляра, а не со всех ссылок сразу. Т.е. грубо говоря перед вызовом метода нужно все поля _data_XXX переназначить на нужные var точки:
как-то так.
------------ Дoбавленo в 13.04:
да еще получается, что после вызова метода нужно восстанавливать значения _data_ полей на исходные, иначе схемы могут не верно работать...

Редактировалось 5 раз(а), последний 2021-05-21 06:24:07

это ничем, кроме формы записи от предыдущего предложения не отличается

Т.е. перед work или var точкой тоже нужно ставить "посредника", который будет делать эту работу. Или это будет делать сам pointer?

------------ Дoбавленo в 16.53:
Допустим - сам pointer. Получается, что pointer должен иметь дополнительно к списку data-точек соответствующий список дата-проксей, а work или var точка pointer-а должна установить на время её работы "отличающееся" значение обработчика события в дата-прокси. А сам дата-прокси не должен хранить весь список (в отличие от эмулятора хаба), а должен хранить лишь оригинальный обработчик (реального элемента) и временный обработчик pointer-а (если работаем через pointer). При этом pointer должен не забывать восстанавливать предыдущее значение обработчика, в таком случае достаточно и одной переменной, хранящей текущий обработчик в дата-прокси.

------------ Дoбавленo в 17.02:
Тогда вместо объекта "дата-прокси" достаточно хранить указатель на переменную _data_xxx реального элемента. Т.е. pointer должен иметь дополнительно к списку data-точек соответствующий список указателей на переменные _data_xxx.

------------ Дoбавленo в 17.03:
Я тут подумал, а что будет, если мы pointer на элемент For сделаем? onEvent везде вызываться будет?

да кстате, перед var действительно нужно делать тоже самое. Еще одно "фи" такого подхода заключается в том, что на любое обращение к любому work или var методу подменять надо ссылки на все data точки элемента, так стандартный кодогенератор не располагает информацией о том, какие data в каком методе используются. Все это вместе взятое заставляет задуматься о целесообразности данного подхода в рамках пакета Windows


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