Ситуация:

есть dialog-based приложение, у него основное окно и куча других, у которых Parent-ом является основное. 
основное окно по таймеру делает какие то вещи, а потом заставляет всех child-ов перерисовать себя на основе новых данных (с помощью спец функции Update, кот есть у всех child-ов)

некий child "A" в определенный момент вызывает модальное окно, в результате чего перестает реагировать на действия пользователя (мышь-клава и тд) - это нормально и правильно

в это время  Parent обрабатывая определенную ситуацию, блокирует всех child-ов через CWnd::EnableWindow(FALSE) а  через несколько секунд опять разрешает их через CWnd::EnableWindow(TRUE). Вообще смысл этих телодвижений - запретить любую активность пользователя во всех окнах приложения на некоторое время.

так вот все это время, у childа "A" модальное окно все еще висит. После вызова CWnd::EnableWindow(TRUE) для childа "A", окно становится доступным для действий пользователя, хотя модальное окно висит.

Как избежать этой ситуации?
Надеюсь понятно описАл....

Пока сделал блокировку ввода для всех окон через CWinApp::PreTranslateMessage c фильтром на мышиные и клавиатурные сообщения, за счет этого убрал портящие все CWnd::EnableWindow(FALSE/TRUE).

Как правильнее блокировать доступность приложения на действия пользователя, не используя CWnd::EnableWindow(FALSE) для всех окон приложения? (ну помимо того способа, что я только что написал)

Да никак. Если ты заглянешь в код DoModal и чуть глубже, ты найдешь кучу EanbleWindow. Если ты сделаешь EnableWindow (true) (другим окнам) во время модального цикла, ввод в них будет доступен. Ибо модальность - это вовсе не недоступность других окон. Это просто отдельный цикл обработки сообщений. Так что делай аккуратно через EnableWindow. 
А еще лучше - сделай SDI-приложение. Не то, чтобы тебе это помогло насчет блокировки ввода, это по-прежнему сам. Но что-то многовато у тебя окон для диалогового приложения. А оно ведь ущербное в каком-то смысле, там нет нормального цикла обработки сообщений.

Добавлено через 1 минуту и 42 секунды
В SDI-приложении, кроме всего, можно сделать обновление доступности окон в цикле простоя на основе текущего состояния - через обработчики OnCmdMsg.

вот то, что EnableWindow (true) перебивает модальность окна, для меня оказалось неприятным сюрпрайзом...


одновременно не более 3-х. не меньше 2-ух. окно "подложка" для полноэкранного режима, с инфой которая необходима всегда, и что-то еще, в зависимости от того что делает пользователь. 


карта сообщений диалогового окна отличается от карты SDI-based? не очень понял...

в любом случае сделал

вроде это решило проблему малой кровью

Причем здесь карта сообщений? Ты поинтересуйся, как устроено тру-виндоус-приложение. Так вот, dialog-based - это такая нашлепка на спине слона. Все оно работает фактически во время инициализации виндоус-приложения, которое потом так и не стартует.

все это конечно красиво... кроме наличия/отсутствия "документ-вид" между SDI и диалоговым окном гугл мне отличий не дал, про это я был в курсе...

если есть желание - распишите чутка подробнее, что имели ввиду, или ссылку. с удовольствием прочту.
в любом случае СПАСИБО за участие  

Это сообщение отредактировал(а) deniska - 26.6.2013, 08:56

Написала я достаточно подробно и совершенно конкретно, детали можно увидеть в коде, который мастер тебе сгенерировал. Не все же у Гугла спрашивать.  
Кроме отсутствия документа-вида у диалогового приложения напрочь отсутствует диспетчеризация командных сообщений. Которая, на мой взгляд, является едва ли не самым полезным в MFC-оболочке. И которая позволяет вполне изящно решать задачи, подобные твоей, а не лепить горбатого.