Последствия работы с отладчиком
Напомню, что в разделе "MinDBG: простой отладчик для Win32" главы 4, рассказано о том, насколько более устойчива отладка в 32-разрядных верcиях Windows, по сравнению с 16-разрядными, потому что в первом случае подчиненный отладчик находится вне адресного пространства основного отладчика. VB-отладчик понимает только интерпретируемый р-код, поэтому в результате подчиненный VB-отладчик выполняется в том же самом адресном пространстве, что и основной. Большинству разработчиков на Visual ) Basic известно, что VB не присущи проблемы, аналогичные тем, которые \ порождает применение указателей в С-программах, но ошибочный компо нент, загружаемый приложением VB, может привести к аварийному завершению VB IDE и потере части проекта.
Следующие три конкретных правила должны помочь читателю разумно использовать VB-отладчик:
- будьте крайне осторожны при подклассификации или использовании операции AddressOf;
- в общем случае, во время отладки считайте, что исходный код имеет атрибут "только-для-чтения" (read-only);
- при отладке не пользуйтесь остальной частью IDE.
Подклассификация (subclassing) в программировании для Windows — это метод, позволяющий приложению перехватывать и обрабатывать сообщения, посланные некоторому окну, прежде чем оно сможет обработать его. — Пер.
Будьте крайне осторожны при подклассификации или использовании оператора AddressOf
Большинство VB-приложений прекрасно выполняются под отладчиком. Однако если приложение подклассифицирует элементы управления Windows или вы используете операцию AddressOf, чтобы переслать одну из ваших подпрограмм как перехватчик обратных вызовов или процедуру таймера, то следует соблюдать особую осторожность, потому что приложение выполняется в том же самом адресном пространстве, что и VB-отладчик. Отлаживая приложение, необходимо учитывать, что обратные вызовы и таймеры могут все еще выполняться после того, как приложение будет остановлено, в результате приводя к аварийному завершению IDE.
Если выполняется подклассификация оконной процедуры в режиме перерывания внутри VB-отладчика, то после получения сообщения окном, которое вы подклассифицировали, IDE завершится аварийно. К счастью, из-за того что подклассификация окон — такая общая операция, Microsoft обеспечивает решение с помощью утилиты DBGWPROC.DLL. Эта DLL позволяет подклассифицировать окна во время работы с VB-отладчиком. DBGWPROC.DLL можно найти по адресу http://msdn.microsoft.com/vbasic /downloads/controls.asp.
Если оператор AddressOf используется для передачи одной из подпрограмм приложения функциям обработки прерываний, обратных вызовов или таймера операционной системы, то никакой помощи, подобной DBGWPROC.DLL, ждать не приходится. При желании, конечно, можно запустить приложение под VB-отладчиком. Однако всегда следует выполнять приложение (до завершения) таким образом, чтобы любые обработчики прерываний и обратные вызовы не выполнялись. Если для остановки приложения используется команда End меню Run или комбинация клавиш <Ctrl>+<Break>, то могут возникнуть ситуации, в которых ваша процедура не находится больше в памяти, поэтому IDE завершится аварийно.
Для обхода проблемы, связанной с AddressOf, можно рекомендовать другую методику, которая включает специальную отладочную функцию, чистящую любые обработчики прерываний, обратные вызовы и таймеры, и которую можно вызывать либо специальной кнопкой в приложении, либо через окно Immediate. При наличии такой функции уменьшается вероятность ошибочных обращений к приложению, которые могли бы вызвать аварийный останов IDE.
В общем случае, во время отладки считайте, что исходный код имеет атрибут "только-для-чтения" (read-only)
VB IDE настроена так, чтобы облегчать редактирование исходного кода и не останавливать выполнение во время сеансов отладки. Многие разработчики чувствуют, что эта возможность — одно из лучших свойств отладчика. Однако пользоваться им нужно с предельной осторожностью.
Чтобы автоматически сохранять все исходные файлы при запуске приложения в отладчике, нужно установить специальный режим VB IDE — Save Changes.
Для этого следует установить флажок Save Changes на вкладке Environment диалогового окна Options. Если исходный код исправляется "на лету" (on the fly), то рекомендуется сохранять изменения как можно чаще (на случай, если VB-отладчик завершится аварийно). Лично я не делаю каких-либо изменений во время выполнения приложения в отладчике и никому не советую. Я полагаю, что, находясь в отладчике, нужно выполнять отладку, а не редактирование. Ведь добавить ошибку во время редактирования легче, чем устранить ее в ходе кропотливой отладки.
При отладке не пользуйтесь остальной частью IDE
Поскольку всю работу по управлению приложением во время отладки выполняет IDE, то могут возникнуть некоторые проблемы, если попытаться в IDE получить доступ к свойствам приложения, не связанным с отладкой. Например, если приложение использует уведомления таймера для фоновой обработки, и вы раскроете какое-нибудь модальное окно, скажем диалоговое окно Open Project или Options, то таймерная процедура приложения может перестать получать сообщения таймера.
При работе в VB-отладчике рекомендуется использовать его отладочные окна. Если в приложении есть специализированный код (таймеры или немодальные диалоговые окна), то любое дополнительное взаимодействие с IDE может привести к тому, что приложение будет получать сообщения, которые не являются нормальной частью прикладного процесса. Вследствие того, что окна приложения являются частью той же самой очереди поточных сообщений, что и от IDE, в некоторых случаях работа отладчика будет затруднена из-за тесного взаимодействия между основным и подчиненным отладчиком. Наихудший случай — необходимость отладки сообщений нажатия клавиш мыши или клавиатуры. В этих ситуациях для отладки кода можно использовать только операторы Debug. Print.
