Программирование на Visual C++. Архив рассылки

A. На этот вопрос пришли похожие ответы, суть которых сводится к совету перекрыть функцию PreTraslateMessage и все нажатия обрабатывать там. Такие ответы прислали Igor Sorokin , Дмитрий Елюсеев и Alex Hin.

Dmitri A. Doulepov советует также обратить внимание на функцию IsDialogMessage. 

Я поясню – эта функция вызывается из CWnd::PreTranslateMessage для того, чтобы определить, предназначено ли сообщение для диалога. Если да, то она обрабатывает это сообщение, проверяет клавиатурные сообщения и конвертирует их в команды диалогового окна (например, TAB преобразуется в команду перехода к следующему элементу управления.) 

Пример:

BOOL CAboutDlg::PreTranslateMessage(MSG* pMsg) {

 // TODO: Add your specialized code here and/or call the base class

 if (pMsg->message==WM_KEYUP && pMsg->wParam==VK_DOWN) {

  MessageBox("DOWN KEY WAS RELEASED!");

  return TRUE; // уберите это, если хотите, чтобы

  // сообщение еще обработалось и стандартным образом

 }

 // вызываем стандартную обработку, оттуда будет 

 // вызвана PreTranslateInput, откуда, в свою

 // очередь, вызывается IsDialogMessage

 return CDialog::PreTranslateMessage(pMsg); 

}

В ПОИСКАХ ИСТИНЫ

Я решил, что будет лучше публиковать по одному вопросу в выпуске. Так и размер выпусков будет меньше (повторюсь, меня не раз укоряли за то, что выпуски получаются слишком "тяжелые"), да и проще ссылаться на вопросы – по номеру выпуска. 

Вопрос сегодняшнего выпуска:

Q. Нужно изменить шрифт у одного элемента типа CStatic. Делаю это функцией SetFont(CFont font). Фонт меняется у элемента … и у всего окна :(. Включая кнопки и другие элементы типа static. Мне его надо было толстым сделать, так у меня такие кнопки стали — загляденье:)) Кто-нибудь знает в чем дело и как решить?

LiMar

Предлагаю подписаться на дружественную рассылку:

COM/DCOM - вокруг да около

Все на сегодня. Пока!

 mailto:jenter@mail.ru

Красноярск, 2000.

Программирование на Visual C++ Выпуск №9 от 11/07/2000

Здравствуйте, уважаемые подписчики!

ОБРАТНАЯ СВЯЗЬ

Из входящей почты

Мы с вами уже разобрали ответы на вопрос о том, почему в Debug-версии все иногда работает нормально, а в Release появляются большие проблемы (этот вопрос был задан в выпуске №5). Уже после того, как вышел выпуск с ответами на этот вопрос, пришли еще несколько писем на эту тему. Большинство сожалеет о том, что такой "элементарный" нюанс – а именно, чреватость использования макроса ASSERT, – остался вне обсуждения.

Для тех, кто не понял, в чем здесь дело: макрос ASSERT(<условие>), в отличие от сходного макроса VERIFY(<усл>),  работает только в Debug-версии, а в Release-версии этот макрос просто заменяется пустой строкой, следовательно условие, которое указывается в скобках, не проверяется. Таким образом, если ваша программа нашпигована такими вот макросами, и вы компилируете ее как Release, проверка всех условий совершенно незаметно для вас исчезает.

А теперь у меня вопрос к авторам таких ответов: Каким образом в Debug-версии все может быть нормально, если исчезновение ASSERT'ов оказалось критичным для работы Release-версии? (Хотя, если честно, один такой способ существует, и именно его, скорее всего. имели ввиду авторы писем. Но я просто никогда  еще не встречал таких оригиналов, которые в условие  макроса ASSERT умудрятся впихнуть что-нибудь помимо самого условия,  выделение памяти или инициализацию объекта, например. Никогда так не делайте! Впрочем, уверен, что большинство до такого все-таки не додумалось ;) 

Итак, выходит в Debug-версии программа должна была вылетать на "Assertion failed", а это вряд ли можно назвать "нормальным выполнением". Напоминаю, в самом вопросе утверждалось, что в Debug программа работает без проблем.

Вообще, макрос ASSERT предназначен как раз для того, чтобы именно Debug-версия и не работала , если у вас что-то в программе не в порядке! Таким образом, программист сможет сразу понять, что и где у него не так (это, конечно, в идеале ;).