Почему возникает ошибка доступа к контролу из другого потока?

Question

[Павел Китьян]

Сразу оговорюсь, вручную потоки я не создаю в коде. Но может быть дело в использовании класса, который управляет взаимодействием через SerialPort?
Стараюсь придерживаться шаблона MVP.
Presenter инстанцируется после запуска приложения и получается указатели на созданные экземпляры классов форм и класса SerialPortManager, который управляет соединением через COM-порт.
Если обработчик события, в котором я меняю контролы на формах, висит на событиях с самих форм - всё ОК.
Или, если просто обратиться в Presenter-е к контролам (через сеттеры, описанные в интерфейсах, которые реализуют классы форм) - тоже хорошо.
Но если обработчик в Presenter повесить на кастомное событие, которое генерится в объекте класса SerialPortManager (а оно там возникает после постобработки события SerialPort.DataReceived), тогда всё. Кирдык.

Получается что?
1) Объект, работающий с SerialPort находится в отдельном потоке?
2) Обработчик, которые лезет к контролам, описан в другом классе (в Presenter), почему же в зависимости от источника события разные потоки получаются?

Прошу без фанатизма, совсем недавно начал разбираться с C#.

Answer 1

[Станислав Макаров]

> Объект, работающий с SerialPort находится в отдельном потоке?

Цитирую из https://msdn.microsoft.com/en-us/library/system.io... :

The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.

А вообще, если есть еще какая-то логика обработки данных, приходящих из порта, то лучше вызывать ее в ивенте DataReceived, и уже в ней, после необходимой обработки, отправлять более высокоуровневые сообщения в GUI-поток через какую-нибудь очередь сообщений, например организованную с помощью ConcurrentQueue. Тогда ваш GUI-поток будет дергаться не по приходу пары байт, а тогда, когда вам самим это будет нужно. Но это уже архитектурный вопрос, который я вас советую продумать, если у вас не одноразовая лаба.

Comments

[Павел Китьян]

Спасибо. Не дочитал я значит. Собственно парсинг потока байт и формирование различных событий более высокого уровня для GUI сделаны уже сейчас. Либо устройство присылает в порт слово состояние, собственно, индикаторы я по нему и переключаю. Либо сыпятся асинхронные события самого устройства. Они тоже обрабатываются в классе менеджера порта, а в презентер уже улетает событие "Произошло то-то и то-то".
Поток GUI дергается не по приходу пары байт, а по факту прихода логического сообщения. По факту - по приходу байта завершения посылки.

А вот что даст в данном случае очередь сообщений?

[Павел Китьян]

Invoke-и я использовал, да. Но вот понимание, почему поток другой - не было. Буду внимательнее читать.
Дело еще в том, что у меня один из кастомных контролов (мнемосхема устройства) выполнена как WPF в ElementHost. Я всё думал на это. Но потом выяснилось что и для кастомных Windows Forms контролов то же самое...

[Станислав Макаров]

Очередь сообщений абстрагирует ваше межпоточное взаимодействие - отправитель (ваш менеджер порта) будет помещать в нее логические сообщения, а потребитель (в данном случае - GUI поток), будет извлекать их оттуда время от времени (когда ему удобно) и обрабатывать (менять состояние контролов). Своя очередь бы вам понадобилась наверняка, если б у вам был не GUI-поток, а, например, серверный, обработывающий запросы из сети. А так как вам операционка фактически уже дает очередь (которая по определению есть у каждого окна и куда летят события мыши/клавиатуры/перерисовки), то вполне вероятно Invoke-a, который через нее работает, вам будет достаточно. Собственно еще один плюс своей очереди сообщений - то что она отделена от виндовой - если у вас Invoke-и от менеджера портов будут приходить слишком часто, виндовая очередь будет захламляться ими, вытесняя WM_PAINT, и интерфейс будет туго перерисовываться. В случае отдельной очереди вы можете просматривать ее тогда, когда сами считаете нужным (например, не чаще чем раз в полсекунды).

[Павел Китьян]

Nipheris: Да, согласен. Очереди прекрасно ложились в основу взаимодействия цикла UI и обработки данных в LabVIEW- приложениях.
Здесь я не задумался об этом потому что producer один и consumer один. Кроме того, устройство подключено слейвом по RS485, поэтому его сообщения идут только в ответ на запросы приложения. Но буду и иметь ввиду! Больше спасибо!