Всем привет...
Сталь необходимо не в консольной программе создать некоторый аналог dos'ого getch'а или kbhit'а
Т.е. хотелось, чтобы у пользователя была возможность "остановиться и прочитать" что ему пишут в STATIC или EDIT окошке...
Например, во время выполнения цикла стало необходимо известить пользователя о том, что молоко убежало и после того, как он на это прореагирует (нажмет на любую клавишу), продолжить работу...
Аля имессагеБокс выскочил, и пользователь нажал на заветную кнопочку Хорошо, но только он не выскочил на самом деле...

Если MessageBox вызвать, то он выскочит, никуда не денется... (если, конечно, твой цикл не в рабочем потоке). Раз не выскочил - значит неправильно вызываешь.
getch как в консольных приложениях ... ну можно, скажем, нарисовать цикл выборки сообщений (GetMessage или PeekMessage) и не выходить, пока WM_KEYDOWN не придет. Но это самый тупой способ, сойдет только если у тебя одно окно в котором один статик на все приложение. Но тогда, спрашивается, чего тебе в консоли не живется? Или только на время отладки алгоритма.

C WM_KEYDOWN не подойдет, слишком уж это не эффективо, да и плюс хотелось, чтобы нажатие на enter и ему подобных тоже считалось реакцией пользователя... У меня была идея с таким циклом, но подходящих типов сообшений я не нашел...

В каком смысле WM_KEYDOWN неэффективно? ENTER тоже должно попадать в WM_KEYDOWN, как и все прочие клавиши. Еще раз, объясни, зачем тебе это нужно. Если только для отладки - одно, если должно жить в работающем приложении, то совсем по-другому делать надо, чтобы все трудилось без глюков.

Цитата(Earnest @ 3.10.2005, 21:06)

В каком смысле WM_KEYDOWN неэффективно?

Плохо выразился, не WM_KEYDOWN плох, а GetMessage, поскольку может поток отправить поспать, что долго по времени. Хотя эти издержки полная чушь в моей задаче, так что я погорячился, когда написал это.

Цитата(Earnest @ 3.10.2005, 21:06)

ENTER тоже должно попадать в WM_KEYDOWN, как и все прочие клавиши.

Я думал, что если нажать на ENTER и ему подобные, не нажимая никаких других клавишь, то WM_KEYDOWN не проидет. Видимо я ошибся

Цитата(Earnest @ 3.10.2005, 21:06)

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

Мне это нужно для нормальной работы приложения.

Ну, чтобы не спать, можно использовать вместо GetMessage PeekMessage.
Но, как я уже говорила, если ты хочешь, чтобы остальные сообщения обрабатывались нормально, пока ты ждешь клавишу, придется полную обработку сообщений в этом цикле писать: все эти TranslateMessage, DispatchMessage, и т.д., все, что у тебя там есть.

В общем, нормальных способов 2 и ни один из них не похож на getch():

1) разбиваешь цикл на итерации (т.е. то, что выполняется между 2мя нажатиями). Т.е. у тебя должна быть функция или объект, который за один вызов выполняет одну итерацию. (Объект лучше, потому что придется хранить промежуточные параметры цикла). В управляющем окне просто ставишь обработчик WM_KEYDOWN. Поймал - выполнил итерацию. Если надо, чтобы проталкивание происходило независимо от того, находится ли управляющее окно в фокусе, придется вставлять фильтр в главный цикл обработки сообщений (типа MFC-шного PreTranslateMessage).

2) цикл не разбиваешь, но переносишь в рабочий поток. Создаешь event (с автосбросом), которое проверяешь в начале каждой итерации (или не каждой, по необходимости). Управляющее окно (или фильтр PretranslateMessage) остаются, конечно, в главном потоке. Там все то же самое, только вместо вызова метода объекта, взводится event.

Второй способ лучше тем, что во-первых, не разбивается код обработки (цикла), во-вторых, не возникает проблем с реакцией приложения даже если итерации выполняются заметное время. Но он требует хорошей проработки механизма синхронизации + если из обработки нужно что-нибудь рисовать или как-то иначе общаться с окнами, тоже требуются дополнительные прокладки.

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

Ну 2-ой способ слишком сложен для моей задачи, а первый вполне подойдет... Спасибо тебе
Earnest единственному и неповторимому, не заленившемуся дать начинающему совет. Товарищи, троекратное ура ему. и плюсик тоже можно
Полагаю, что тема закрыта

ЗЫ
нашел функцию MsgWaitForMultipleObjects которая идеально решила поставленную задачу.
Это так, на будующее

Да, но:
1) пока ты сидишь в MsgWaitFor... поток стоит и все остальные сообщения (кроме тех которые ловишь) не обрабатываются (прорисовка там, etc)
2) функция хороша, если тебе надо ждать какие-нибудь объекты ядра, и при этом реагированть на сообщения. Ты какие объекты ядра ждешь? Никакие? Тогда цикл GetMessage дает абсолютно то же самое. Резюме: микроскопом гвозди...