.net System.Threading.Timer требуется доступ к компоненту пользовательского интерфейса Silverlight 3 при обратном вызове.

Question

У меня есть страница Silverlight 3. Я использую System.Threading.Timer для выполнения асинхронного вызова службы WCF. Я делаю вызов, передавая класс страницы Silverlight («this») в качестве объекта «state» в конструкторе таймера и получая к нему доступ через прокси клиента службы. Делая это таким образом, обратный вызов из службы WCF срабатывает нормально.

Моя проблема (насколько я понимаю) состоит в том, что возврат из вызова WCF происходит в отдельном потоке, и, таким образом, я получаю ошибку доступа, когда пытаюсь получить доступ / изменить элементы пользовательского интерфейса на странице Silverlight.

Во-первых, правильно ли я понимаю проблему?

Во-вторых, каков наиболее архитектурно правильный метод решения этой проблемы?

Спасибо за любую помощь.

Answer 1

Использование this.Dispatcher.BeginInvoke необходимо для перемещения выполнения кода в потоке, который имеет доступ к элементам пользовательского интерфейса. Однако некоторые мысли могут стоить применять. Это может быть легко сделать это: -

 this.Dispatcher.BeginInvoke(() => {

      // The whole body of code needed
 });

Однако есть несколько вещей, которые следует учитывать. Если весь пакетный код будет выполнять какую-либо значительную работу, не связанную с доступом к элементам пользовательского интерфейса, лучше сначала сделать это, а затем переключаться на поток пользовательского интерфейса только тогда, когда у вас есть все вместе для изменения пользовательского интерфейса. Это может означать изменение порядка, в котором происходят события, возможно, даже использование нескольких переменных для удержания значений до более позднего момента.

Во-вторых, если один и тот же обратный вызов используется очень часто из самого потока пользовательского интерфейса, то, возможно, было бы лучше перестроить код, эти обратные вызовы запускают код без использования функции сидячей функции или BeginInvoke. Метод Dispatchers CheckAccess поможет вам определить, нужен ли BeginInvoke. Однако в вашем конкретном сценарии BeginInvoke всегда будет необходим.

Answer 2

Нашел ответ: мне нужно было обернуть код обратного вызова в:

this.Dispatcher.BeginInvoke(() => { code here });

Подробнее: http://msdn.microsoft.com/en-us/library/ms591206.aspx