Действительно ли BackgroundWorker подходит для AsyncOperationManager?

Вот что я пытаюсь решить:Действительно ли BackgroundWorker подходит для AsyncOperationManager?

Мой класс (который может быть размещен приложением пользовательского интерфейса или службой Windows или что-то еще), должен получать сообщения Windows. Где-то здесь кто-то дал предложение (и некоторый исходный код) создать форму окна в отдельном потоке, который будет создавать форму, и всякий раз, когда сообщение Windows, которое меня интересует, получает в WndProc, оно вызывает делегат, использующий контекст .После.

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

Из тестов, которые я сделал, я ожидаю, что он будет работать очень хорошо, когда я буду использовать пользовательские интерфейсы, но мой вопрос: есть ли какие-либо советы против использования BackgroundWorker, когда вы не имеете дело с пользовательскими интерфейсами?

Edit: Пути я представляя его, каждый раз, когда моя форма «ребенка» (один работает в фоновом режиме рабочего) получает сообщение, я издам ReportProgress. Единственное, что мне нужно передать через потоки, это идентификатор сообщения, поэтому технически это должно быть достаточно право?

источник

2010-01-25 Padu Merloti

Как часто вы планируете обновлять пользовательский интерфейс от пользователя backgroundworker? – SwDevMan81

Я думаю, что макс. частота должна быть примерно раз в 5 секунд ... но нормальный случай будет один раз каждые 2-10 минут. –

BackgroundWorker и окно - это вода и огонь. Для окна требуется поток STA и цикл сообщений, которые не предоставляются BGW. Проверьте свой ответ в this thread для альтернативы.

источник

2010-01-25 20:36:32

Очень интересно. Я оставил вопрос на вашем оригинальном посте, но я все равно спрошу. Причина, по которой я начал использовать SynchronizationContext, был фактом (по крайней мере, понятным мною), что он не требует, чтобы хост находился в слое пользовательского интерфейса, поэтому не нужно вызывать Invoke. Можете ли вы по-прежнему использовать свою модель, если клиент DeviceChangeNotifier - это библиотека, работающая в службе NT? –

Этот код на самом деле ничего не делает для маршалирования вызова события в другой поток, он поднимается в фоновом потоке. Вам нужно будет добавить синхронизацию самостоятельно по мере необходимости. Что не обязательно в службе, вы ничего не можете синхронизировать. –

Я бы сказал, что если его максимум каждые 5 секунд, то вам следует передать сообщение id (as userState) обратно через событие ReportProgress.

источник

2010-01-25 20:21:37 SwDevMan81

И почему бы не так, если бы это было, скажем, каждую секунду или порядка 100 мс? –

Поскольку пользовательский интерфейс станет неактуальным: http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/9ea431a7-588d-4452-a711-42e64338ac7e/ – SwDevMan81

Еще более подробный ответ здесь: http: //social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/ee8b2e1e-a614-41ce-8707-cc31215dd758/ – SwDevMan81

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

источник

2010-01-25 20:28:41

Действительно ли BackgroundWorker подходит для AsyncOperationManager?

ответ

Смежные вопросы