Снегопат

Решил вот посоветоваться.
Сейчас принята стандартная OLE-Automation модель привязки к событиям, порождаемым объектом Designer, на базе интерфейсов IConnectionPoint
Однако есть у нее недостатки.
Для скриптописателей неудобна тем, что нельзя контролировать когда реагировать на событие, а когда нет.
Если есть обработчик события, то он вызывается всегда при возникновении события.
Все помнят о неизбежных глобальных флагах в скриптах при обработке например OnMessageBox, OnDoModal, OnFileDialog и тд и тп.
Также обработчик события может быть только один на весь скрипт. И если например создается несколько объектов, каждый из которых хочет реагировать на событие, приходится самому вести список этих объектов и руками в событии дергать каждый этот объект.

Для Designer'а неудобно тем, что нельзя указать конкретные события, к которым привязывается получатель - если он привязывается, то сразу ко всем событиям.
То есть если в скрипте есть обработчик хотя-бы одного события, то скрипт дергается при любом событии, независимо от того, есть в нем обработчик этого события или нет.

Поэтому я хочу перейти на систему, похожую на модель "сигнал-слот" из QT.
У объекта Designer сделать два метода - connect и disconnect.
В методе connect указывается имя события, к которому хотим привязаться, объект-получатель события, имя обработчика события в объекте.
Например:

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

Есть у кого-нибудь мысли на эту тему?

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

При необходимости, на базе твоего предложения можно сделать универсальный код по установке обработчиков и вызов его при начале начале аддина.
Например, этот код может подписывать только те методы, у которых в начале наименования стоит "onEvent" - например, метод onEventDoModal
Т.е. часть скриптов вызывает один простой метод для простой установки всех нужных обработчиков, а часть вызывает напрямую connect и disconnect

Вопрос: твое предложение на события от форм 1С также распространяются? или там останется, как есть сейчас? полностью автоматически при загрузке формы?

Я думаю, для форм это удобно и достаточно.
Там в loadScriptForm третьим параметром можно указать префикс, который будет добавляться к именам обработчиков, думаю этого достаточно.
те если делать loadScriptForm(путь, SelfScript.self, "form1_")
то обработчики будут искаться как "form1_ИмяОбработчикаВФорме"
это на случай, если один объект захочет обрабатывать события нескольких форм, и в них есть одинаковые события.
Тогда можно делать

Я за новую событийную модель.

А это надо в вики:

_________________
С уважением,
Александр Кунташов
Канал про 1С в Телеграме: @kuntashov_devnotes

Хочу получить список всех возможных событий, но не могу найти их описание.
поиск по connect в скриптах дает результаты, но хочется полного списка.
На форуме также ничего не нашел.
(orefkov) Выложишь?

Пока не выложу.
Можно сделать поиск по скриптам "events.connect(", вроде для всех событий есть примеры, кроме "onMessage"

Добавил в Вики краткий перечень и некоторое описание найденных событий
События Снегопата

onChangeTextManager вообще не нашел описания -
Саш, в описании изменений по событию ты писал "для SciColorerV8"
Подскажешь описание события?
Зы можно сразу в Вики