Обновление компонентов пользовательского интерфейса из асинхронного обратного вызова - PullRequest
2 голосов
/ 01 ноября 2010

Теперь я знаю о Dispatcher и DispatcherTimer и их преимуществах. Но у меня всегда было впечатление, что обратный вызов асинхронного веб-сервиса / WCF (обработчик завершенных событий) автоматически обрабатывается потоком пользовательского интерфейса.

Но, глядя на некоторые ссылки в Интернете, такие как ссылка, приведенная ниже, кажется, что это НЕ тот случай.

Итак, странно то, что я не использовал Dispatcher для обновления пользовательского интерфейса (обновления связанных с данными ObservableCollections) в событиях, завершенных службой, но я никогда не получал межпотоковые исключения.

Кто-нибудь может объяснить, почему я не видел это исключение, или подтвердить, правильно ли мое первоначальное предположение?

Ссылка: http://www.silverlightshow.net/items/Tip-Asynchronous-Silverlight-Execute-on-the-UI-thread.aspx

Ответы [ 2 ]

0 голосов
/ 02 ноября 2010

Самое простое объяснение состоит в том, что это зависит от того, как вы извлекаете свои данные и пытаетесь ли вы обновить пользовательский интерфейс. Например, при непосредственном использовании HttpWebRequest его всегда нужно маршалировать обратно в поток пользовательского интерфейса. Однако, если вы используете WebClient, то это сделано для вас. WCF также сделает вам маршалинг.

"Прокси WCF в приложениях Silverlight используют SynchronizationContext потока, из которого инициируется вызов веб-службы, для планирования вызова асинхронного обработчика события при получении ответа."

http://tomasz.janczuk.org/2009/08/improving-performance-of-concurrent-wcf.html

Другими словами, WCF будет перенаправлять вызов обратно в поток, из которого он был вызван. Так что, если вы вызываете ваши сервисные вызовы из потока пользовательского интерфейса, они будут возвращаться в поток пользовательского интерфейса. Если вы вызываете свои сервисы в другом потоке, вам нужно выполнить маршалинг самостоятельно.

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

0 голосов
/ 02 ноября 2010

Диспетчер помещает сообщение в обычную очередь сообщений Windows.Если вы обновляете элемент, связанный с элементом пользовательского интерфейса, вам не нужно использовать диспетчер, потому что PropertyChanged, возникающий при обновлении модели, уже помещает сообщение в очередь сообщений Windows, поэтому вам не нужно вызывать диспетчера, в противном случаеВы просто делаете две поездки в очередь сообщений окна.

...