@Oryel

Ранее похожий вопрос поднимался.
Но все же....

Исходные данные: Программа , в которой реализовано несколько различных режимов( протоколов ) для общения с устройством (устройство абстрактно , т.е. черный ящик). Используются readfile/ writefile в асинхронном режиме по потокам.
Есть класс, который реализует передачу по порту.

Поток с формой отправляет запрос. Поток второстепенный постоянно включен и ждет сообщений. Работают они через класс device (мой класс, отвечает за передачу по порту прием/передача/формирование пакета). В зависимости от протокола сложность приема растет. В одних командах нужно просто принять команду и вывести без сохранения или обработки. Только форматированный вывод удобный для пользователя.

Вопрос первый. Как лучше организовать такой вывод? Тут меняются в зависимости от команды: поле вывода (memo1, memo2), интерпретация принятого пакета, количество пакетов, количество байт в пакете.

Кроме того . устройства могут послать ошибку, задержаться с ответом и т.п. Это начинает играть роль, когда нужно не просто вывести пакет, а по прибытию пакета/пакетов обработать и выполнить n-операций.

Вопрос 2. как в таком случае лучше всего ждать прибытия сообщения/сообщений. Вот пользователь нажал кнопку, послал запрос и осноного потока с формой и где и как ждать прибытия пакета? Слип- невариант. А если обмен интесивный? запрос, ответ, подтвежредние
______________________________________

Мой взгляд. Поток приема. Максимально инкапсулировать все. Вместо поле memo поток выводит в некое абстрактное поле мемо, а конкретное поле будет зависит от команды путем выбора указателя. Можно так? Самый простой способ, есть указатель на мемо, а в команде берется адрес конкретного мемо. (возможно и оптимально ли в билдере такое?)

Трудности начинаются с интерпретацией. Нужно в зависимости от команды выбрать интерпретацию. Вот тут нет красивых идей.
Аналогично с приемом, если несколько кадров и их значения используются не только для вывода..отправил команду...где и сколько ждать ее?

Пока что в классе девайс сделал поле с флагом Данные готовы, при отправке поле очищается, при приеме ставиться. В входной буфер помещается один пакет. Минусы такой реализации, прием одного пакета (подшаманить и можно несколько пакетов) и где-то нужно ждать и проверять флаг и учесть, что может быть ответа вообще не будет...таймаут софтовый.
Подчеркну...основная проблема прием пакета/пакетов и их обработка, после запроса. Нужно как-то узнать что пришло n пакетов при этом где-то это событие ожидать. после приема провести операции...

Стоит запись отвести от основного потока с формой? Намного ли усложниться тогда структура и контроль за прогой.?


.....
Отдельный вопрос потокобезопасности. Как узнать жив поток/действует и т.п. Мб в статус бар инфу вывести о его состоянии...но как узнать состояние? у меня синхронно толлько вывод происходит, установка флага готовности данных и заполнений буфера девайса принятым пакетом.

Рад любым идеям...мне не хочется грабли делать и наступать на них.

0

@vxg

Oryel, делайте так как этого требует задача. Для примера: есть форма, на ней кнопка послать запрос, после нажатия устанавливаем флаг, поток с Sleep(100) в бесконечном цикле проверяет флаг, если флаг установлен идёт запрос и приём в этом же потоке, после приёма результат сохраняем в некой переменной или присваиваем некой переменной код ошибки, устанавливаем флаг "запрос обработан" и либо шлем сообщение окну приложения через post либо в приложении работает таймер анализирующий флаг "обработан" либо этот флаг анализируется в OnIdle приложения, тем или иным способом уведомленное о завершении операции приложение отображает результат через GUI

0

@Oryel

Спасибо за ответ. Я сам решил большую часть поставленных проблем более менее приемлемо (граблей).
Опыта еще мало, сначало надо более детально мне задачу исследовать, составить иеархии, выделить паттерны и т. п .

Остальные вопросы решатся по ходу. Спасибо за ответ.

1