обрубка ивентов [C#]
есть один контролл который бросает ивент
этот контрол сам подписан на этот ивент, и он включен во множество других контролов и форм, также подписаных на этот ивент
в обработчике ивента контрола есть условие
- если оно не выполняется return; - после этого запускаются обработчики вышестоящих контролов.
- если же условие выполнилось слелать определенные действия (а вот тут уже не надо чтоб этот ивент обрабатывали вышестоящие подписсчики)
как можно обрубить этот "списк подписки" из обработчика ивента этого контролла? шарп вообще ткое позволяет?
[SIZE="1"]можно конечно ввести паблик переменную и проверять ее в перентах этого контролла, но это во первых криво, во вторых надо менять во всех ивентах, в третьих надо еще все время об этом не забывать ну и наконец это уже не ООП получается)
кстати встречаюсь с этим уже второй раз. но в прошлый раз было намного меньше перентов, и обработчик ивента в контролле содержал одну строку - просто скопировал ее во все перентовские обработчик с проверкой.[/SIZE]
этот контрол сам подписан на этот ивент, и он включен во множество других контролов и форм, также подписаных на этот ивент
в обработчике ивента контрола есть условие
- если оно не выполняется return; - после этого запускаются обработчики вышестоящих контролов.
- если же условие выполнилось слелать определенные действия (а вот тут уже не надо чтоб этот ивент обрабатывали вышестоящие подписсчики)
как можно обрубить этот "списк подписки" из обработчика ивента этого контролла? шарп вообще ткое позволяет?
[SIZE="1"]можно конечно ввести паблик переменную и проверять ее в перентах этого контролла, но это во первых криво, во вторых надо менять во всех ивентах, в третьих надо еще все время об этом не забывать ну и наконец это уже не ООП получается)
кстати встречаюсь с этим уже второй раз. но в прошлый раз было намного меньше перентов, и обработчик ивента в контролле содержал одну строку - просто скопировал ее во все перентовские обработчик с проверкой.[/SIZE]
- Чувак, я нихрена не понял что ты сказал. Но ты мне близок. Ты заговорил - и достучался до сердца... (с)
Нет, до-диез ленгидж не аллоуз ту гет ор чендж инвокейшн лист ивента произвольным манне, к нему можно лишь применять операторы += и -=
Почему бы не внести в элемент управления собственное событие, происходящее в нужном вам случае?
Нет, до-диез ленгидж не аллоуз ту гет ор чендж инвокейшн лист ивента произвольным манне, к нему можно лишь применять операторы += и -=
Почему бы не внести в элемент управления собственное событие, происходящее в нужном вам случае?
Или выделить отдельный класс, который будет ответственным именно за логику оповещения о данном событии - что-то типа паттерна "Наблюдатель".
Т.е. ему на оповещение подписываются различные классы, инициатор события кидает его наблюдателю, и тот решает кто должен получить их.
Например, наблюдатель кидает ивент, первому в списке... Тот обрабатывает событие и в один из аргументов передаваемых с событием, ставит true. Что означает, что он его обработал и остальным оно не нужно. Если же этот аргумент остается в false, то событие кидается по-очереди всем остальным подписанным на него контролам...
Т.е. ему на оповещение подписываются различные классы, инициатор события кидает его наблюдателю, и тот решает кто должен получить их.
Например, наблюдатель кидает ивент, первому в списке... Тот обрабатывает событие и в один из аргументов передаваемых с событием, ставит true. Что означает, что он его обработал и остальным оно не нужно. Если же этот аргумент остается в false, то событие кидается по-очереди всем остальным подписанным на него контролам...
В вашей схеме можно обойтись без декомпозиции на разные объекты.
Цепочка обязанностей, основанная на комбинированном делегате с изменяемым параметром, применяется при обработке событий от клавиатуры, например. Но там ситуация ровно противоположная: параметр используется для того, чтобы определить, следует ли обрабатывать событие его инициатору.
Если мы говорим о событиях как о механизме .NET, то здесь есть нюанс: обработчики вызываются в порядке подписки на событие, и изменить или прервать его нельзя. Тем не менее, схема вполне жизнеспособна, поскольку можно сделать собственный список обработчиков, используя методы доступа к событию add и remove. Увлекаться, правда, не стоит, поскольку иногда она может спротиворечить принципам применения событий в .NET.
Жаль, но похоже, что, всё это - решение другой задачи. :) Простого сепаратного события автору должно быть вполне достаточно.
Цепочка обязанностей, основанная на комбинированном делегате с изменяемым параметром, применяется при обработке событий от клавиатуры, например. Но там ситуация ровно противоположная: параметр используется для того, чтобы определить, следует ли обрабатывать событие его инициатору.
Если мы говорим о событиях как о механизме .NET, то здесь есть нюанс: обработчики вызываются в порядке подписки на событие, и изменить или прервать его нельзя. Тем не менее, схема вполне жизнеспособна, поскольку можно сделать собственный список обработчиков, используя методы доступа к событию add и remove. Увлекаться, правда, не стоит, поскольку иногда она может спротиворечить принципам применения событий в .NET.
Жаль, но похоже, что, всё это - решение другой задачи. :) Простого сепаратного события автору должно быть вполне достаточно.
Может и другой :) Автор особо задачу-то и не описал :)