Обычно это случается при написании кода диалоговой процедуры на чистом Win API. Причина такого неприятного эффекта заключается в том, что ваша диалоговая процедура организована следующим образом:
{
. . .
switch(msg)
{
case ...:
. . .
break;
case ...:
. . .
break;
}
return TRUE;
}
|
Рассмотрим, что же происходит в таком случае с окном диалога. Оконная процедура диалогового окна (системная функция, выполняющая реальное управление внешним видом и состоянием окна) направляет весь поток сообщений, приходящих окну, в диалоговую процедуру (функцию, которую вы регистрируете при создании окна диалога как пользовательскую процедуру обработки сообщений, приходящих окну диалога). Эта последняя может выполнить необходимые действия в ответ на приход какого-либо сообщения, а может и не делать этого. Для обратной связи с оконной процедурой предусмотрен следующий механизм уведомления о произведенных действиях:
В последнем случае оконная процедура самостоятельно выполняет необходимые с ее точки зрения манипуляции.
Теперь становится ясно, что при организации обработки сообщений в диалоговой функции таким образом, что она по-умолчанию завершается возвратом TRUE, диалоговая функция запрещает какие бы то ни было действия с окном после того, как она отработала. Тем самым оконной функции не дается никакого шанса выполнить собственно отрисовку любых полей окна, за исключением контролов, которые "живут отдельной жизнью".
Исправить положение легко - нужно изменить завершающий оператор return так, чтобы он возвращал FALSE. В этом случае оконная процедура будет выполнять дополнительную обработку всех сообщений (которая в большинстве случаев сводится к вызову DefWindowProc( ) для окна диалога), кроме тех случаев когда case будет явно оканчиваться return TRUE. Если в справочном руководстве по обработке сообщения нет явного указания о необходимости возврата TRUE, обработчик сообщения должен обеспечить возврат FALSE (либо явно, либо посредством break + return FALSE).