Графика для Windows средствами DirectDraw

Если покопаться в заголовочных файлах MFC, вы увидите, что в отладочном режиме макрос ASSERT определяется так:

#define ASSERT(f) \
 do \
 { \
 if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \
 AfxDebugBreak; \
 } while (0) \

Выглядит довольно странно. Но вместо того, чтобы пытаться расшифровать логику его работы, мы согласимся с тем, что макрос работает, и попытаемся изменить его так, чтобы он правильно работал в приложениях DirectDraw. Однако перед этим следует заметить, что вывод диалогового окна и завершение приложения выполняются с помощью вызова AfxAssertFailedLine. Следовательно, любой код, добавленный в этот условный оператор (что на первый взгляд кажется логичным), выполняться не будет.

Теперь давайте подумаем, что нужно сделать для нормального отображения диалогового окна. Можно вызвать функцию DirectDraw FlipToGDISurface и обеспечить вывод диалогового окна на первичной поверхности, но проблема с палитрой при этом остается, к тому же окно может быть выведено в неверном видеорежиме. Вместо этого мы воспользуемся функцией RestoreDisplayMode — это гарантирует вывод диалогового окна, активизацию стандартной палитры Windows и возврат к исходному видеорежиму Windows. Видоизмененный код выглядит так:

#define ASSERT(f) \
 do \
 { \
 if (!(f)) \
 { \
 if (GetDDWin) \
 { \
 GetDDWin->GetDDraw->RestoreDisplayMode; \
 GetDDWin->GetDDraw->Release; \
 } \
 AfxAssertFailedLine(THIS_FILE, __LINE__); \
 AfxDebugBreak; \
 } \
 } while (0) \

Для работы с объектом DirectDraw применяются функции GetDDWin и GetDDraw (которые соответственно возвращают указатели на объект DirectDrawWin и интерфейс DirectDraw). Помимо вызова функции RestoreDisplayMode мы для приличия освобождаем объект DirectDraw. Также обратите внимание на перестановку, в результате которой наш код будет выполняться перед вызовом функции AfxAssertFailedLine.

Перейдем к макросу VERIFY. Возвращаясь к заголовочным файлам MFC, мы находим, что в отладочной версии VERIFY реализуется с помощью макроса ASSERT:

#define VERIFY(f) ASSERT(f)

Вспомните — в отладочной версии ASSERT и VERIFY ведут себя одинаково. Раз ASSERT и VERIFY реализуются одним макросом, VERIFY можно оставить без изменений. Сказанное относится и к окончательным версиям макросов ASSERT и VERIFY, потому что нам не потребуется изменять их поведение. При компиляции окончательной версии ASSERT и VERIFY определяются так:

#define ASSERT(f) ((void)0)
#define VERIFY(f) ((void)(f))

Как было сказано выше, выражение, передаваемое макросу ASSERT, удаляется из окончательной версии (в действительности оно заменяется выражением ((void)0), которое игнорируется компилятором). Выражения, передаваемые VERIFY, остаются в коде программы, однако их значение больше не проверяется.

Нам остается лишь переопределить стандартный вариант ASSERT из MFC своим нестандартным вариантом. Для этого необходимо сначала отменить определение макроса из MFC. Кроме того, нужно позаботиться о том, чтобы подстановка осуществлялась только в отладочной версии. Окончательный код выглядит так:

#ifdef _DEBUG#undef ASSERT#define ASSERT(f) \
 do \
 { \
 if (!(f)) \
 { \
 if (GetDDWin) \
 { \
 GetDDWin->GetDDraw->RestoreDisplayMode; \
 GetDDWin->GetDDraw->Release; \
 } \
 AfxAssertFailedLine(THIS_FILE, __LINE__); \
 AfxDebugBreak; \
 } \
 } while (0) \
#endif _DEBUG

Модифицированный макрос находится на CD-ROM и готов к работе, поэтому если вы захотите внести изменения в какую-нибудь программу, то можете свободно пользоваться макросами TRACE, ASSERT и VERIFY. Кроме того, этот код автоматически генерируется и включается в проекты, создаваемые DirectDraw AppWizard.

Удаленная отладка

Процесс отладки упрощается, если вам повезло и в вашем распоряжении оказались два компьютера, объединенных в локальную сеть. В этом случае возможна удаленная отладка, при которой на одном компьютере работает отлаживаемая программа, а на другом — отладчик Visual C++. При удаленной отладке исчезают все проблемы, связанные с переключением страниц, палитрами и отображением отладчика. Отладчик всегда присутствует на экране и с ним можно работать, потому что отладчик и приложение работают на разных компьютерах. Даже если ваша программа «сломается», ее состояние можно будет просмотреть в отладчике. Поскольку удаленная отладка обладает такими преимуществами (и при этом так плохо документирована), мы поговорим о том, как происходит ее настройка. Если эта тема вас не интересует, можете пропустить этот раздел.

Для выполнения удаленной отладки вам понадобятся два компьютера, объединенных в локальную сеть. Конкретные параметры сети (количество узлов, тип кабеля, сетевые адаптеры и т. д.) не имеют значения; главное — чтобы на обоих компьютерах был установлен сетевой протокол TCP/IP. Кроме того, необходимо установить на обоих компьютерах Visual C++.

Затем вы должны выбрать, на каком компьютере будет работать отладчик Visual C++, а на каком — приложение. Мы будем называть компьютер, на котором работает Visual C++, хостовым компьютером (или хостом), а компьютер с отлаживаемым приложением — удаленным компьютером. Обычно хостом назначают более мощный из двух компьютеров.

Вам необходимо узнать адреса TCP/IP для обоих компьютеров. Проще всего получить этот адрес с помощью утилиты Winipcfg (WINIPCFG.EXE). Для Winipcfg не существует ярлыка (shortcut) или команды меню Start, поэтому придется либо создать ярлык или команду (утилита находится в каталоге Windows), либо запустить Winipcfg из окна DOS или диалогового окна Run меню Start. Окно утилиты Winipcfg изображено на рис. А.1. В поле IP Address приведено значение адреса TCP/IP . В нашем примере удаленный компьютер имеет адрес 128.128.128.1 (а хостовый компьютер будет иметь адрес 128.128.128.2).