Разница в обработке событий в Silverlight и WPF - проблемы схожести потоков - PullRequest
Новая
       8

Разница в обработке событий в Silverlight и WPF - проблемы схожести потоков

0 голосов
/ 05 июля 2011

Я занимаюсь разработкой приложения Lync Silverlight в Silverlight и сейчас пытаюсь перевести его на WPF.

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

Теперь это отлично работает в silverlight, но, по-видимому, не разрешено в WPF.Теперь мои вопросы:

  1. Почему это работает в Silverlight, а не в WPF, хотя Silverlight должен быть подмножеством WPF?

  2. Сходство с потоками является важной концепцией, и я знаю, что мы можем использовать диспетчер invoke, но разве это не превосходит концепцию асинхронного программирования в форме обработчиков событий и обратных вызовов?

  3. У меня есть кнопка, определенная на моей странице XAML, и определенный для нее обработчик события click может обращаться к другим элементам пользовательского интерфейса, она не страдает от проблемы, описанной выше.

    Но если я определю экземпляр LyncClient в своем коде позади, определенные для него обработчики событий не смогут получить доступ к элементам пользовательского интерфейса.Почему так, я не обнаружил такой разницы между UIElements и другими объектами в Silverlight?

1 Ответ

0 голосов
/ 08 июля 2011

Исходя из вышеизложенных комментариев, я предложу следующий «ответ» ...

Я бы предположил, что, скорее всего, чем-то отличается то, как SL API былнаписано, что из WPF API.Это может объяснить разницу в потоке, который используется, когда API выполняет обратный вызов.Чтобы убедиться в этом, вы можете:

  1. Спросить MS напрямую
  2. Вставить некоторый диагностический код в ваш метод обратного вызова, чтобы зарегистрировать идентификатор потока и сравнить его с основным потоком приложения.Сделайте это для SL и WPF, чтобы увидеть, являются ли они одинаковыми или разными потоками.
  3. Откройте сборки в Reflector, чтобы проверить, как был написан каждый API.

С точки зрения обработки этой конкретной ситуации в вашем обратном вызове вы могли бы:

  1. Получите объект диспетчера (для SL отличается от WPF) и всегда выпускайте обновления пользовательского интерфейса через Dispatcher.Invoke.
  2. Используйте привязку данных и INotifyPropertyChanged для изоляции пользовательского интерфейса от свойства.Вы можете удалить свойство в ViewModel или в коде позади.Затем привяжите текстовое поле пользовательского интерфейса к этому свойству.Привязка данных имеет несколько смартов, которые автоматически перенесут изменения свойств в нужный поток (в большинстве случаев в любом случае).

Надеюсь, это поможет.

...