Сон Веры Павловны
Как бы намек
Спасибо, в примере увидел GetInvocationList(), в документации к которому сказано:
Returns the invocation list of this multicast delegate, in invocation order
И:
Invoking these delegates sequentially, in the order they appear in the array, produces the same results as invoking the current instance.
Т.е., какой-то порядок есть, но какой он, не сказано.
Сон Веры ПавловныИ да, при использовании явной реализации событий (add/remove) разработчик внутри класса может организовать хранение цепочки делегатов в любом виде (см. у Рихтера главу "Explicitly Implementing an Event" и выше про класс EventSet), и порядок вызова здесь может быть абсолютно произвольным. И завязывать архитектуру, опираясь на предположения о каком-то порядке вызова делегатов события - признак того, что с архитектурой что-то не так.
Про оба этих ваших предложения. У нас нет возможности повлиять на архитектуру. Мне надо наследоваться от контрола из закрытой библиотеки (без исходных текстов). Этот контрол выполняет важное действие "Обработка1" по событию "Событие1" в другом, вложенном в него контроле. Мне в наследнике тоже надо подписаться на тот вложенный контрол (он public). И мне важно, чтобы действие "Обработка1" происходило обязательно до того как сработает мой метод в наследнике, тоже срабатывающий по тому же событию "Событие1".
И да, с помощью рефлекшена получилось: перед подпиской в моем наследнике отписать все остальные делегаты с помощью EventInfo.RemoveMethod, сохранив их; подписать наследника на свой метод, который будет вызывать сначала все остальные делегаты, гарантировав выполнение нужного метода "Обработка1", а потом выполнять уже свое действие.
Не думаю что базовая архитектура механизма событий изменится в будущем, и что изменятся/пропадут: метод EventHandler.GetInvocationList и поля EventInfo.AddMethod и EventInfo.RemoveMethod.
Тест уже показал что все получается
Спасибо большое за подсказку!
