Prism CompositeEvent не сработал с анонимным делегатом фильтра, указанным вспомогательным классом - PullRequest
Новая
       7

Prism CompositeEvent не сработал с анонимным делегатом фильтра, указанным вспомогательным классом

3 голосов
/ 30 января 2011

У меня есть класс TestEvent, как указано ниже: 

class TestEvent: CompositePresentationEvent<object>
    {
        public void Subscribe(Action<object> action, int number)
        {
            this.Subscribe(action, ThreadOption.PublisherThread, false, arg=>arg.Equals(number));
        }
    }

Если я подписываюсь на событие следующим образом: 

eventAggregator.GetEvent<TestEvent>().Subscribe(_=>MessageBox.Show("Hi"), 3);

Событие не запускается.Однако, если я подпишусь на это так: 

eventAggregator.GetEvent<TestEvent>().Subscribe(_ => MessageBox.Show("Hi"), ThreadOption.PublisherThread, false, arg => arg.Equals(3));

Это «срабатывает».Хотя концептуально, синтаксически и логически оба похожи.Единственное отличие состоит в том, что первый использует вспомогательный метод в классе события для подписки на событие.

Я уверен, что это связано со слабой ссылкой на делегат, которая хранится в классе CompositeEvent, потому чтоПервый работает, если я установил keepSubscriberAlive = true (третий аргумент) в вызове подписки.Я не могу просто пойти с этим решением, потому что я не знаю, что это будет жить?это будет класс, который подписался на событие?Если так, то класс жив, даже не передавая false, тогда почему событие не запускается / не обрабатывается в первом случае?

Может кто-нибудь объяснить это поведение?

1 Ответ

3 голосов
/ 30 января 2011

В первом примере код захватывает переменную, переданную методу TestEvent.В этом случае компилятору необходимо создать класс, который переносит число.Новый экземпляр этого класса следует создавать каждый раз, когда вызывается подписка TestEvent.

Во втором примере нет данных для захвата, поэтому делегат, который передается в подписку, можно сделать статическим.В этом случае он будет жить до выгрузки домена.

...