MFC: что выбрать SDI или просто диалог

[ann_nef]

Я запуталась. Просто направьте, куда тыркнуться.
Задача:
есть прибор, подключенный к СОМ-порту, посылаю ему информацию и получаю от него ответ.
Ответ или 16 байт, или в цикле ,пока не остановишь.
Тестов и режимов много, много входных разных настроек, вывод подученных данных на экран или по потребности в файл.

Решила использовать MFC, чтобы не тратить время на написание многочисленных меню и настроек.
Начала писать , используя просто Диалог с меню + доп.диалоги для настроек.
Временно решила,что результат вывожу в поле Edit на весь экран.(неудачный вариант для большого количества информации).

Подскажите, как грамотней организовать вывод результата на экран?
По какому из 3-х путей всё-таки пойти в MFC (MDI, SDI или продолжать писать в Dialog)?

"Только не бросайте меня в терновый куст"

[Алексей++]

CEdit  пойдёт, только надо шрифт для диалога выбрать моноширинный (например Courier) , чтобы колонки не расползались Это можно в редакторе ресурсов сделать

Dialog-based приложение тоже пойдёт для тестов. А там посмотришь

[ann_nef]

Да, пока обходилась Dialog-based.
Но, сейчас переписываю циклический запуск сценария - в DOSе вывод результата шёл, пока не нажимали какую-либо клавишу.
(вот еще доп.вопрос: Как это осуществить? Какое событие может закончить этот бесконечный опрос?)

Сейчас 500 циклов запускала(задала кол-во опросов), и только по окончании их вывелась иформация в CEdit.
Что делать,чтобы результаты появлялись на экране во время опроса? Поток организовывать или что?

[x77]

в цикле обновлять содержимое окна. WM_UPDATE или типа того.

[Джон]

Если данных очень много и их изменение хочется видеть в (почти) реальном времени, то тут возникает проблема медленной отрисовки графики. Под ДОС  в текстовом режиме такой проблемы не было.

Решение - FIFO-буфер. Порт пишет в него данные, окно забирает по мере возможности.

Это так к слову. Теперь по теме.

1. MFC SDI очень даже подойдёт.
2. CEdit? Для отображения? а) из пушки по воробьям; б) при хороших скоростях будет очень медленным. Гораздо быстрей собственное окно вывода, которое кстати и завязать с FIFO-буфером.

зы Эти решения были использованы в реальном проекте для тестирования приборов подключаемых к различным портам COM, LPT, USB, IEEE1394.

[x77]

Джон, там пока дело не в отрисовке, а в том, что цикл не отдаёт управление основному потоку, пока не завершится. поэтому пока идёт цикл - окно "пустое", даже если реально в нём что-то есть, оно просто проапдейтиться не успевает. выход - внутри самого цикла заставлять перерисовываться окно. тупо слать ему соответствующую мессагу или использовать какие-то методы класса: Update, Invalidate - как там это у вас называется? скорость упадёт, на больших объёмах - упадёт на порядок, но инфа будет выводится в окне сразу. как вариант, можно обновлять CEDIT не на каждой итерации цикла, а на 5-й - 10-й.

[ann_nef]

Буду пробовать.

[Алексей++]

Джон, отображение в CEdit тормозить не будет, ведь перерисовку можно сделать не чаще, чем, скажем, раз в полсекунды. Я так делал ))

ann_nef, поток - самое удобное. Ну а можно и подпинывать очередь сообщений в цикле основного потока, классика

Код:

	MSG msg;
	while(GetMessage(&msg, NULL, 0, 0))
	{
		TranslateMessage(&msg);
		DispatchMessage(&msg);
	}

но это всё потом боком как-нибудь выйдет. А вот если приложение не будет более ничего особенного делать - пусть и так сойдёт )

[Джон]

Джон, отображение в CEdit тормозить не будет, ведь перерисовку можно сделать не чаще, чем, скажем, раз в полсекунды.

Лёш, я ведь не просто так это говорю. Если у тебя мегабайты шуруют на 115200 бод (например, когда парни из Siemens сканируют чековые книжки в цвете, а на компах стоит WinNT 4, которая про USB ни сном ни духом), то он заткнётся как пить дать. Я просто через всё это был прошёл и даже начинал с CEdit, поэтому выложил готовые решения.

CEdit по натуре медленный. Ведь для подобного отображения необходимо сделать его многострочным, значит каждый раз будет включаться логика проверки переноса строки. Плюс скролл. Да ещё не забывай о максимальном размере данных для CEdit, который придётся увеличивать. А как? Динамически? Или сразу установить максимальное значение, которое кстати тоже конечно? Короче, его можно использовать ТОЛЬКО в качестве "пабысраму протестить", но не как окно вывода данных для данной задачи. Ды ты только представь себе как ты будешь его апдейтить! Тебе придётся перелопачивать кучу текста, добавляя к существующему новые строки, каждый раз снова его инициаллизируя. Это оооочень меееедленно. Да просто открой в Блокноте большой текстовый файл и засеки время. Поймёшь о чём я говорю.

Своё же окно свободно от этих недостатков. Во-первых, ты всегда знаешь сколько данных необходимо в нём отобразить (размер окна тебе известен и размер отображаемой строки тоже). Значит ты забираешь только эти последние данные из FIFO-буфера сразу, куском. Поскольку это окно у тебя напрямую связано с FIFO-буфером, оно является как бы отображением его состояния и никаких проблем с апдейтом окна не возникает, при условии конечно, что буфер заполняется другим тредом, но это ессно. Во-вторых, логика скролла тоже в твоих руках. Ну и в-третьих, дизайн отображения тоже имеет значение. В своём окне ты можешь, например, сделать линии, отделяющие столбцы с инфой, отображать данные в виде символов, ESC- и/или HEX-значений и тд и тп. Вот примерно так:

а это с доп инфой

зы Использование TranslateMessage-DispatchMessage является практически стандартным решением подобной проблемы, о чём неоднократно мы говорили здесь на форуме, и никаких "потом боком как-нибудь" не выйдет. "И кильками в наш век гораздо легче отравиться, нежели водкой. Пейте смело." (с) Булгаков

[Алексей++]

Ну, коли не выйдет - хорошо Но выйти может, если поток не один

[Джон]

Даже если не один. У меня изначально UI развязано с портами и транслятором.

зы Ты про сообщения? Так и не надо их тогда, они именно нужны в одном потоке, когда апдейт окон задерживается.

[Алексей++]

ну для этого случая - да