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

Jenter Алекс
Шрифт:
В ПОИСКАХ ИСТИНЫ 

Q. Есть приложение на базе диалога. По некоторым причинам необходимо уже внутрь этого диалога вставить закладки (страницы свойств, как хотите). Все это нормально делается и проблем тут не возникает. Но вот при использовании клавиши Tab для прогулки по диалогу фокус с последнего контрола, не принадлежащего Property Page, перемещается не на закладку страницы, а на ее первый определенный в Tab Layout контрол, и только после пробегания по всем элементам Property Page попадает на закладку. Как это вылечить?

George Orlov 

Это все на сегодня. Счастливо! 

Алекс Jenter jenter@mail.ru Красноярск, 2001.

Программирование на Visual C++

Выпуск №39 от 1 апреля 2001 г.

Добрый день, уважаемые подписчики! С праздником вас!

СТАТЬЯ

Диагностические средства MFC

Автор: Олег Быков 

Библиотека MFC предоставляет программисту мощный набор средств для отладки приложений любой сложности. Данная статья ставит своей целью последовательное рассмотрение диагностических средств для помощи начинающим MFC-программистам в выборе и более полном их использовании.

Разработка коммерческих приложений всегда подразумевает написание стабильно работающих систем, и, как следствие, наличие в коде тотальной проверки всего на свете – входных параметров функций, возвращенных значений, полученных указателей и т.д. Но за стабильность приходится платить замедлением работы программы. MFC предлагает следующий подход к проблеме: разработчик вставляет в код набор диагностических макроопределений, которые при невыполнении заданных условий сообщают имя исходного файла с ошибкой, номер строки, и останавливают работу программы. При этом данные макроопределения выполняются только при отладочной сборке проекта (Debug build).

Иными словами, в код помещаются проверки, которые выполняются только в отладочной версии программы, и не включаются в код при окончательной сборке (Release build). За время работы с отладочной версией программы (в идеале) выясняются и устраняются все возможные ошибочные ситуации и надобность в замедляющих работу проверках отпадает (здесь не имеются в виду ошибки, на которые программа должна реагировать определенными действиями. В частности, не стоит проверять таким образом результаты работы API-функций, так как нельзя гарантировать корректность возвращаемых ими значений и в отладочной сборке, и в окончательной). Чтобы стало понятней, рассмотрим несколько диагностических макроопределений.

ASSERT и VERIFY

ASSERT – пожалуй, один из самых часто употребляемых макросов. Принимая в качестве аргумента булево значение, ASSERT продолжает работу программы, если это значение равно TRUE, и прерывает работу программы в ином случае. При этом ASSERT выводит информационное окно с именем исходного файла и номером строки, содержащей сработавший макрос, и предоставляет разработчику выбор – окончательно прервать работу программы (Abort), переключиться в окно отладчика (Retry) или продолжить работу (Ignore).

В качестве примера использования ASSERT можно привести проверку входного значения функции:

void CPerson::SetPersonAge(int nAge) {

 ASSERT((nAge>=0) && (nAge<200)); // сработает при любых x, меньших 0

 m_nAge = x; // или больших 199

}

При срабатывании макроса (то есть, при передаче неверного nAge) у разработчика есть возможность переключиться в окно отладчика и через список вызовов (Call Stack) определить, откуда был передан ошибочный параметр.

ПРИМЕЧАНИЕ

ASSERT развернется в код только при Debug-сборке. Чтобы обеспечить вычисление параметра и в окончательной версии проекта (в случае, когда в ASSERT вызывается нужная функция), используйте макроопределение VERIFY. При Debug-сборке этот макрос полностью идентичен ASSERT, но, в отличие от него, при Release-сборке VERIFY разворачивается в код и вычисляет значение своего аргумента, хотя при этом никак не влияет на ход выполнения программы.

В MFC определен вспомогательный макрос DEBUG_ONLY, который служит для обеспечения выполнения своего параметра только при Debug-сборке. В Release-версии приложения выражение внутри DEBUG_ONLY будет проигнорировано.

ASSERT_KINDOF и ASSERT_VALID

Эти макросы предназначены для диагностики состояния объектов. ASSERT_KINDOF принимает два параметра — имя класса и указатель на объект - и срабатывает (прерывая выполнение программы подобно ASSERT) в случае, когда объект, переданный по указателю, не является объектом данного класса или одного из потомков данного класса. Пример использования макроса:

CPerson::CPerson(CPerson &newPerson) {

 ASSERT_KINDOF(CPerson, &newPerson); // сработает, если в конструктор