Фичи и баги OWEN Logic

[wal79]

Да не. Я ж не в укор.
Меня как раз по тому предложению и напрягло то, что макрос в общем случае НЕ ФУНКЦИЯ, а, как минимум, ПРОЦЕДУРА (а ещё точнее - объект, имеющий "собственное состояние"). А анализ схемы ведётся как для функции. Поэтому устранить неоднозначность поведения с обратными связями "вокруг макроса", пытаясь учитывать обратные связи внутри него ("прозрачность" без развёртывания), как минимум, очень сложно, как максимум невозможно.

Ну да ладно....
А вот можно ли как-то проработать вопрос с тем, чтобы редактирование макроса не требовало его перевставки в основную схему?
Просто, решение с перевставкой противоречит принципу структурированности программ.
Ну, т.е., если есть программа, использующая компоненты, то редактирование компонента не должно требовать его переопределения в программе.
Иначе получается ерунда.
Пишешь программу, используя десяток экземпляров одного компонента, и при небольшом изменении самого компонента - заново перерисовывать всю программу?
Не логично и не удобно. Даже если количество входов/выходов изменится - это не повод для требования перевставки.

Вы не правы. Изменив количество входов Вы меняете сигнатуру функции. Здесь должны быть вмешательство со стороны пользователя. А если Вы меняете только тело функции, то переустановка макроса на схеме и не требуется. Единственно, есть баг, к сожалению существующий уже на протяжении не одного релиза, если редактируете макрос со вложенностью более 1, то в том макросе, где используется редактирующийся макрос обновление сразу не наступит. Нужно будет заново переоткрыть макрос. Об этом я знаю, и надеюсь будет время в ближайшие сроки исправить.

Конечно, можно сделать то, что Вы хотите, но это уже будет в качестве дополнительного функционала.