При изменении глобальной переменной, не возникает событие onValue во всех глобальных переменных в схеме. Предлагаю добавить такое событие

code_15225.txt

А зачем ? Ты же чем-то меняешь ее значение - поставь на входе doValue хаб-вот тебе событие

Для того она и глобальная переменная, чтобы помещать ее в разные удаленные места
Удобнее подключать к одной точке, чем размножать хабы и каким-то образом тянуть связи через все схему

Как переменную с данными, а не как удаленный источник событий
Для вызова события onValue, необходимо подать событие на doValue, а откуда это событие возьмется на удаленной переменной

неужели не видел откуда

с doValue всех глобальных переменных одного названия
получается что-то подвид LineBreakEx, только не с множества в один, а с множество в множество
Если такое реализовать ооооочень сложно, то извините за беспокойство

Видел. Но этого никто не видел в штатном компоненте. Почему -- вопрос не ко мне

Сразу не увидел, спасибо Доволен как слон

С чем тебя и поздравляю

Почему, как раз совершенно понятно.
Вопрос в том, что вовсе НЕ по причине "откуда ему взяться", а по причине противоречия с принципом масштабируемости схемных решений.

Чего пользователю никто не объяснил, оставивши его довольным аки слон.
Обманывать новичков - не есть хорошо.

Тогда можно оформить такой компонент как менеджер
Например:
- кидаем на рабочий стол первую глобальную переменную (так как она первая, то будет главной - с индексом "0") и даем имя
- кидаем на рабочий стол вторую глобальную переменную и подключаем ее к первой (выбрав имя как в менеджере; с индексом "1")
- кидаем на рабочий стол третью глобальную переменную и подключаем ее ко второй (выбрав имя как в менеджере; с индексом "2")
и т.д.
получаем семейство элементов со своей иерархией, как у менеджеров
можно добавить наследование цвета и ссылки на предыдущий/следующий элемент цепочки
P.S.: Все выше написанное воспринимайте как мысли и идеи для обсуждения

miver, ну и чем же это отличается от GlobalVar с onValue, работающим описанным выше способом?

Ничем
Но дает структурированную структуру с четким пониманием откуда может появиться сигнал или значение (если добавить ссылки на предыдущий/следующий элемент цепочки)

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

Фиг его знает, может и нет такого "термина".
Могу точно сказать, что я под ним имел в виду.

У тебя есть хорошо продуманный и отлаженный кусочек схемы. Ты помещаешь его в контейнер, и начинаешь пользоваться им как элементом: то ли в виде простых копий этого мультика, то ли в виде связанных.
И если таковой не один, то у тебя появилась как бы своя элементная база (библиотека), специфическая для твоих задач. И тебе даже и не надо знать внутреннее устройство мультика - знаешь точки и их назначение, и этого вполне достаточно.
Это один уровень масштабирования.
Можно решать и более крупные задачи, создавая более функциональные элементы - это будет следующий уровень.
И так далее, без ограничения на уровень сложности решаемых задач.

Собственно, именно так все всегда и делают (это не изобретение HiAsm).
И у нас это все прекрасно работает, пока мы не начали лепить всякие там GlobalVar. Сделал копию, а там где-то у нутрях затесалась переменная с тем же именем. А ты уже и забыл за нее.
Искать такую ошибку будешь - мало не покажется. "Надежное программирование" как раз и заключается в том, что таких внезапных ошибок не должно возникать. Сделал, отладил, и оно обязано теперь работать всегда
А если еще и нотификацию с Ex-а будешь использовать - вообще веру в программирование потеряешь, наверное.

Я так и понимал этот термин
Добавлю только, что GlobalVar нужен не столько для построения мультика сколько для связывания готовых элементов в одну общую программу
Думаю, что нет причин не включать такую модификацию в стандартный пакет HiAsm
Что по этому поводу скажет "начальник транспортного отдела"