Интенсивная отладка средствами отладчика Visual Basic. Отладка программ

Отладчик Microsoft Visual Basic — интересная программа. Разработчики ее или любят, или ненавидят. Во-первых, отладка с его помощью некоторых приложений — таких, например, как элементы управления Microsoft ActiveX (написанные на Visual Basic), становится тривиальной. Во-вторых, этим отладчиком довольно легко пользоваться. И, наконец, окно Immediate является моделью того, что должны включать все отладчики, — оно отображает "мгновенный снимок" процесса отладки.

С другой стороны, с отладчиком Visual Basic (VB) связан ряд серьезных проблем. Первая, которая чрезвычайно раздражает, когда вы пытаетесь прослеживать трудные ошибки через множество сеансов отладки, заключается в том, что интегрированная среда разработки Visual Basic (VB IDE) не сохраняет между сеансами точки прерываний и элементы окна наблюдения Watch. К сожалению, для решения этой проблемы ничего сделать нельзя. Вторая проблема заключается в том, что основной и подчиненный отладчик разделяют одно и то же адресное пространство, так что когда один из них завершается аварийно, то же самое происходит и с другим (этот вопрос рассмотрен подробнее чуть ниже). Последняя проблема возникает из-за того, что VB-отладчик отлаживает не совсем тот код, который будут выполнять пользователи. Он имеет дело с интерпретируемым р-кодом, который создается VB-компилятором.

В этой главе описывается работа VB-отладчика и даны некоторые рекомендации для обхода его ограничений, основанные на здравом смысле. Начнем с того, что определим, что означает отладка в Visual Basic. Затем рассмотрим режимы перехвата ошибок и покажем, как "выжать" максимум из окон Locals, Immediate и Watch. Наконец, как и в главах по отладчику Microsoft Visual C++, приводится несколько советов и специальных приемов.

Опытные разработчики знают все о р-коде языка Visual Basic (VB), но необходимо, чтобы каждый читатель совершенно точно понимал, что происходит, когда выполняется VB-приложение, и представлял себе последствия отладки VB-приложений. Наряду с другими аспектами отладки, понимание работы отладчика может чрезвычайно помочь в этом. Для того чтобы установить систему определенных понятий, начнем с небольшого урока истории.

Visual Basic 1, представленный в 1991 году, был многообещающим прогрессом в средствах программирования. В начале 90-х, разработки для Microsoft Windows необходимо было писать на языке С средствами SDK, что было, вообще говоря, довольно сложно и требовало больших усилий. Visual Basic обещал и, в большинстве случаев, предоставлял возможность "рисовать" интерфейс пользователя (UI) при помощи инструмента, получившего название WYSIWYG (What-You-See-Is-What-You-Get — "что -вы -видите, то -вы -и получаете"), и легкий способ связывать код с событиями пользователя, такими как щелчок кнопкой мыши. Необычным свойством в Visual Basic I было то, что он компилировал окончательное приложение не в "родной" выполняемый код, а в форму, называемую р-кодом.

Термин р-код (p-code — сокращение от packed code, переводится как "упакованный код") происходит от названия метода сокращения объема памяти для хранения двоичных файлов (размер р-кода намного меньше, чем код языка ассемблера для процессоров Intel x86). При "компиляции" приложения в Visual Basic 1 создается регулярный выполняемый код, но это только оболочка для р-кода. Когда запускается "компилированный" двоичный файл (с этого начинается так называемое "время выполнения" (run-time) программы), по определенному смещению в памяти отыскивается р-код и начинается его выполнение. Известно, что вместе с приложением должна быть загружена большая библиотека динамической компоновки (DLL) VBRUN100.DLL, которая содержит интерпретатор р-кода.

DLL иногда называют также библиотеками времени выполнения (run-time library). — Пер.

Интерпретатор р-кода — стековая машина, которая транслирует специальные коды операций в операции CPU. Во времена MS-DOS и 16-разрядных Windows компания Microsoft предлагала иную форму р-кода, генерировавшуюся в системах программирования C/C++ 7.x. В действительности, первоначальные 16-разрядные версии продуктов Microsoft Word, Excel и PowerPoint широко использовали р-код этой системы в своих UI-кодах, чтобы достичь компромисса "размер памяти/производительность" и обеспечить выполнение этих приложений в операционных системах с ограниченной памятью (например, выпускавшихся тогда Windows 3 и 3.1). С идеей реализации р-кода в системах C/C++ 7.x, которая, вероятно, близка к реализации р-кода в Visual Basic, можно ознакомиться в библиотеке MSDN, найдя тему "Microsoft P-Code Technology" (Технология р-кода компании Microsoft).

Все версии Visual Basic от 1-й до 4-й генерировали только р-код. Самая большая проблема в его применении состояла в том, что он был медленнее, чем исполняемый двоичный. Старая шутка гласила, что вы общались с Visual Basic на расстоянии в целую милю (потому что приложение работало очень медленно, т. к. использовало трехмерные элементы управления для всех текстовых кнопок). Компания Microsoft никак не могла повлиять на выбор разработчиками элементов управления, но учла просьбу "номер один" разработчиков Visual Basic, требовавших возможности компилировать исполняемые файлы.

Начиная с Visual Basic 5, выпущенного в 1997 году, компания Microsoft добавила специальный режим, который поддерживал такую компиляцию. Разработчики Microsoft также переписали исполнительную (run-time) систему Visual Basic, сделав ее быстрее. Результатом обоих изменений было фантастическое повышение производительности приложений Visual Basic. Единственный недостаток заключался в том, что Microsoft сделала лишь точечную прививку свойства родной компиляции к дереву свойств системы Visual Basic, а не полностью интегрировала компиляцию и отладку со средой VB IDE. После компиляции приложения в исполняемый код программисту предоставлялась "полная свобода" в его отладке. Поскольку двоичные файлы Visual Basic не имеют достаточного количества отладочных символов, что обсуждалось в разделе "Отладка компилированного кода Visual Basic" главы 5, разработчик почти вынужден отлаживать программу на необработанном языке ассемблера.

Самый большой недостаток компиляции в исполняемый код заключается в том, что VB IDE понимает только интерпретируемый р-код. Таким образом, VB-отладчик имеет дело с р-кодом, а это совсем не то, что получается в результате — исполняемый компилированный код. С точки зрения отладки и тестирования ситуация неприятная, — даже отдавая предпочтение компиляции в двоичный р-код, вы не отлаживаете точно те биты, которые посылаете заказчикам. К сожалению, ничего не остается, как мучиться с отладкой компилируемого двоичного VB-файла под отладчиком Visual C++. Остается надеяться, что в будущей версии Visual Basic или Microsoft Visual Studio эта проблема будет исправлена, и приложения, отлаженные разработчиками, будут точно соответствовать тому, что получат заказчики.

Напомню, что в разделе "MinDBG: простой отладчик для Win32" главы 4, рассказано о том, насколько более устойчива отладка в 32-разрядных верcиях Windows, по сравнению с 16-разрядными, потому что в первом случае подчиненный отладчик находится вне адресного пространства основного отладчика. VB-отладчик понимает только интерпретируемый р-код, поэтому в результате подчиненный VB-отладчик выполняется в том же самом адресном пространстве, что и основной. Большинству разработчиков на Visual ) Basic известно, что VB не присущи проблемы, аналогичные тем, которые \ порождает применение указателей в С-программах, но ошибочный компо нент, загружаемый приложением VB, может привести к аварийному завершению VB IDE и потере части проекта.

Следующие три конкретных правила должны помочь читателю разумно использовать VB-отладчик:

Подклассификация (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.

Теперь вернемся к режимам перехвата различных ошибок. VB IDE может выполняться в трех режимах: режиме проектирования (когда выполняется кодирование), режиме выполнения (когда приложение выполняется под отладчиком) и режиме прерывания (когда приложение останавливается отладчиком).

Когда приложение наталкивается на позиционную точку прерывания, IDE автоматически переходит в режим прерывания. Однако, когда приложение генерирует ошибку, IDE перейдет (или не перейдет) в режим прерывания, в зависимости от установки трех следующих режимов:

Когда я только начинал программировать на Visual Basic, то долго не мог получить класс, выдававший такую ошибку времени выполнения, которая обрабатывалась бы в режиме прерывания. После изрядных мучений, наконец, было найдено "секретное" меню, которое позволяло устанавливать эти режимы отлавливания ошибок.

Режим перехвата ошибок можно устанавливать на вкладке General диалогового окна Option (открываемого командой Tools|Options). По умолчанию Visual Basic устанавливает режим Break In Class Module. Можно также изменять режим перехвата ошибок "на лету". Для этого нужно открыть (правым щелчком мыши в исходном окне) контекстное меню, выделить пункт Toggle и в раскрывшемся подменю включить нужный режим перехвата ошибок.

Как подсказывает само название режима (прерывать на всех ошибках), всякий раз, когда VB-отладчик сталкивается с ошибкой времени выполнения, он останавливается и открывает диалоговое окно, показанное на рис. 7.1. Прерывание будет вызывать любая ошибка, даже если в программе имеется обработчик ошибок. Вообще говоря, этот режим перехвата ошибок не так полезен и я использую его, только если мне нужно увидеть, где возникла конкретная ошибка и когда она происходит в функции (не обращая внимания ни на какие обработчики ошибок).

Рис. 7.1. Диалоговое окно ошибки времени выполнения Visual Basic

По существу, при установке режима перехвата ошибок Break On All Errors выключаются все обработчики ошибок, встроенные в отлаживаемое приложение. Выполнение прерванного на ошибке приложения может быть продолжено путем перетаскивания стрелочного указателя с текущей выполняемой строки (на которой возникла ошибка) к следующей за ней выполнимой строке или с помощью команды Set Next Statement контекстного меню. Единственная проблема, возникающая в результате изменения строки выполнения, состоит в том, что Visual Basic не будет передавать вам фактическую ошибку для обработки.

Судя по названию, режим Break On Unhandled Errors вынудит отладчик перейти в режим прерывания, если возникла ошибка, а обработчика для нее в программе нет. Этот режим прекрасно работает почти во всех ситуациях и я установил его в качестве режима перехвата ошибок по умолчанию. К сожалению, если отлаживаются системы СОМ-серверов (как внутриза-дачных (in-process), так и внезадачных (out-of-process)), то прерывания на ошибках модулей классов выполняться не будут. При отладке таких систем поступают иначе: возникшие ошибки упаковываются и передаются обратно клиенту как нормальные СОМ-ошибки. Для того чтобы выполнить прерывание в СОМ-серверах, нужно установить режим перехвата ошибок Break In Class Modules.

Этот режим предназначен для отладки СОМ-серверов. Выбирая этот режим перехвата ошибок, вы сообщаете отладчику, что хотите рассматривать все ошибки в модулях классов так, как если бы не было никаких обработчиков ошибок. Хотя режим Break In Class Modules позволяет получать ошибки от СОМ-серверов, пользовательские обработчики ошибок игнорируются по-прежнему.

Заключительные предложения по перехвату ошибок

Как можно понять из этого обсуждения, перехват ошибок в VB-отладчике вряд ли желателен. Если вы хотите останавливаться на ошибках, то вы можете это делать, но за счет способности "переступать" через обработчики ошибок. Единственный реальный обходной путь состоит в том, чтобы устанавливать точки прерывания на всех обработчиках ошибок, которые требуется выполнить в пошаговом режиме, и задать режим перехвата ошибок Break On Unhandled Errors. В чем мы действительно нуждаемся, так это в способе останавливать выполнение при возникновении ошибок, но обрабатывать их при помощи нормальных приемов.

Остается только надеяться, что команда VB-разработчиков сжалится над теми, кто хочет отлаживать свои приложения полностью и предложит для этого удобные, эффективные инструменты. Искусственные ограничения, наложенные на перехват ошибок в VB-отладчике, серьезно затрудняют отладку приложений.

Поскольку проблемы перехвата ошибок связаны непосредственно с конструкциями On Error GOTO в языке Visual Basic, следует обратить особое внимание на использование обработчиков ошибок в программах. Следующий раздел этой главы я собирался посвятить надлежащей обработке ошибок, но Пит Моррис (Peet Morris) сообщил, что соответствующую тему он обсуждает в главе 1 (названной так: "On Error GoTo Hell") книги Advanced Microsoft Visual Basic 6.0, The Mandelbrot Set, 2nd ed., Microsoft Press, 1998. Если вы даже только раздумываете о разработках на Visual Basic, эту главу нужно прочитать обязательно.

До сих пор мы говорили главным образом об ограничениях VB-отладчика, а не о его сильных сторонах. Но, как сказано в начале этой главы, этот отладчик имеет несколько свойств, которые разработчикам нравятся. Для начинающих отладчик Visual Basic намного проще, чем отладчик Visual C++. Он также включает несколько превосходных поддерживающих окон, которые делают отладку довольно простым занятием. В этом разделе рассмотрены три окна VB-отладчика: Locals, Immediate и Watch.

Окно Locals довольно простое, тем не менее обращу внимание читателя на три ключевых момента. Во-первых, в отличие от окна Watch отладчика Visual C++, окно Locals в Visual Basic не требует, чтобы программист тратил силы на приведение типов и прочие хитрости, чтобы значения отображались в соответствующем формате. Во-вторых, наиболее важная переменная, показанная в окне Locals, является Me-объектом. Подобно указателю this языка C++, Me-объект является родовой конструкцией, которая полностью описывает текущий объект и его свойства.

И, наконец, последнее: иногда можно изменять локальные переменные в этом окне, выбрав переменную и щелкнув (кнопкой мыши, конечно) на поле Value. Если Visual Basic позволит изменять переменные, то в поле Value будет разрешено редактирование текста. Visual Basic не позволяет изменять объекты и некоторые переменные типа variant. Например, нельзя изменять какое-либо из свойств элементов управления в коллекциях форм Controls. Однако если в форме имеются переменные с действующими типами элементов управления, такими как CommandButton, то изменение свойств этих элементов через переменные допустимо. В тех случаях, когда нельзя изменять значение переменной в окне Locals, можно воспользоваться окном Immediate.

По моему мнению, окно Immediate Visual Basic изумительно. Хотелось бы, чтобы все отладчики имели такие развитые встроенные возможности отладки. Окно Immediate поддерживает подчиненную отладку и, по существу, является мини-интерпретатором Basic, позволяя выполнять фрагменты кода.

Окно Immediate показывает вывод трассы операторов Debug.Print. Имейте в виду, однако, что это окно обеспечивает отображение лишь 200 строк, поэтому может потребоваться прокрутить строки трассировки (по экрану), для того чтобы прочитать их. К сожалению, нельзя очистить окно Immediate программным способом, чтобы гарантировать просмотр важных операторов трассировки. Надеемся, что в следующей версии Visual Basic будет предложен метод Debug, clear.

Главное преимущество окна Immediate состоит в том, что в нем можно изменять значения переменных и вызывать подпрограммы прямо в приложении. Чтобы увидеть значение конкретной переменной программы, скажем, frmFoo.x, нужно использовать символ ? или оператор Print (т. е. для вывода значения нужно напечатать: ? FrmFoo.x). Прелесть окна Immediate в том, что в него встроены все замечательные IntelliSense-функции Microsoft. Например, если ввести правильное имя объекта, то IntelliSense покажет на экране методы и свойства этого объекта.

Технология IntelliSense известна также под названием Automatic Statement Completion (автоматическое завершение операторов). — Пер.

Для того чтобы изменить значение переменной, просто напечатайте строку кода Visual Basic в окне Immediate — точно так же, как если бы требовалось присвоить значение этой переменной в окне исходного кода. Окно Immediate "знает" все о свойствах "только-для-чтения" (read-only) и синтаксисе языка и известит вас через панель сообщения о том, что какое-либо действие окончилось неудачей.

Один удачный прием, доступный в окне Immediate, позволяет создать приспособление для быстрого тестирования. Например, если вы разрабатываете класс, то можете протестировать его в окне Immediate сразу же, как только напечатаете его код в исходном редакторе. Если этот класс имеет имя clcMyclass и содержит метод с именем DoSomethingMagical, то можете ввести (строка за строкой) в окно Watch следующий код:

и протестировать данный метод. Убедитесь, что восстанавливаете в объектных переменных значение Nothing, чтобы не оставить в окне Immediate инициализированные переменные активными. Если установить точки прерывания в методе DoSomethingMagicai, то можно будет выполнять его пошаговый проход.

Кроме того, окно Immediate поддерживает вызов специальных отладочных функций. Вспомнив правила для ограничений на вызов отладочных функций из окна Watch Visual C++ (см. раздел "Вызов функций в окне Watch" главы 5), вы высоко оцените простоту использования окна Immediate. Единственное ограничение на вызов функций в окне Immediate — функция должна существовать в программе. Трудно сказать, какое свойство интенсивной отладки использовать легче.

Хотя окно Immediate позволяет "одним махом перепрыгнуть небоскреб", оно не позволяет писать полноценное приложение. Первое ограничение: в окне Immediate нельзя писать функции. Второе: окно Immediate выполняет за один раз только одну строку кода. Некоторые структуры управления, такие как циклы For...Next, требуют записи нескольких операторов. Для этого предназначена специальная операция ":", позволяющая располагать операторы в одной строке. Ниже приведен пример записи цикла For.. .Next в окне Immediate:

Как можно предположить, окно Watch предназначено для наблюдения значений переменных внутри программы. Можно устанавливать область видимости (действия) переменной, которую вы хотите наблюдать в окне Watch, легко избегая любой путаницы одноименных переменных в различных частях приложения. Кроме того, в окне Watch определяются условные точки прерывания.

Окно Watch позволяет устанавливать только два типа условных точек прерывания: Break When Value Changes (Прервать при изменении значения) и Break When Value Is True (Прерывать, когда значение равно true). Установка условных точек тривиальна в том смысле, что вы просто раскрываете (щелчком правой кнопки мыши) в исходном окне контекстное меню и выбираете команду Add Watch. Чтобы выполнить прерывание, когда изменяется значение выражения, напечатайте в поле Expression выражение, которое вы хотите наблюдать, и выберите тип Break When Value Changes в групповой панели Watch Type. Чтобы выполнить прерывание, когда выражение оценивается как true, напечатайте выражение в поле Expression и выберите Break When Value Is True. Когда приложение выполнит прерывание в отладчике, удостоверьтесь, что вы находитесь в окне Watch, потому что подсвеченная строка указывает, какие условия заставляют срабатывать соответствующую точку прерывания.

Для того чтобы использовать счетчики пропуска точек прерывания, подобные тем, что предлагались в отладчике Visual C++, нужно будет зарезервировать специальную переменную, которая содержит число вызовов функции, и проверять ее значение в условной точке прерывания для остановки после определенного счета. С этой ролью неплохо справляется статическая локальная переменная.

Можно буксировать переменные (мышью) прямо из исходных окон в окно Watch. Что делает буксировку мышью даже популярнее — так это то, что Visual Basic достаточно "сообразителен" и вычисляет контекст для этой переменной, поэтому его не надо устанавливать вручную. Можно также буксировать переменные в окно Immediate, но IDE трактует такое перемещение как операцию вырезки (cut), так что при этом вы изменяете свои исходные файлы. Для того чтобы редактировать результат буксировки в окне Watch, просто выполните щелчок правой кнопкой мыши в окне Watch и выберите команду Edit Watch всплывающего (контекстного) меню.

Прежде чем переходить к следующему разделу, упомянем еще два аспекта окна Watch. Первый — можно редактировать значения щелчком мыши на поле Value. Так же, как и в окне Locals, если IDE Visual Basic разрешает редактирование, то вы можете изменять значения. Выражения можно также редактировать прямо по месту.

Мне еще нравится помещать в окно Watch специальные значения, такие, например, как Err.Description. Это позволяет следить за любыми ошибочными значениями, с которыми можно столкнуться, если "перешагивать" через функции. Если отлаживаемое приложение получает также параметры из командной строки, я помещаю в окно Watch значение command, чтобы получить возможность быстро проверять различные параметры командной строки, которые приложение могло бы использовать (без необходимости их предварительной установки на вкладке Make диалогового окна Project Properties). К сожалению, как было сказано в начале данной главы, невероятно раздражающее свойство среды VB IDE заключается в том, что она "забывает" все тщательно построенные наблюдения и точки прерывания, как только вы ее покидаете (так что приходится повторно вводить их, начиная каждый новый сеанс отладки).

Как обычно, закончим главу некоторыми советами и особыми приемами, которые призваны облегчить жизнь разработчика, отлаживающего программу.

Добавьте кнопку Run To Cursor к панели инструментов Debug

Подобно отладчику Visual C++, отладчик Visual Basic позволяет выполнять программу до позиции курсора. По умолчанию команда Run To Cursor назначается сочетанию клавиш <Ctrl>+<F8>, но многим нравится при отладке использовать мышь, а этой замечательной команды нет на панели инструментов Debug. На вкладке Command диалогового окна Customize выберите категорию Debug и перетащите кнопку Run To Cursor на панель инструментов Debug.

В Visual Basic 6 можно заметить, что если создать кнопку Run To Cursor на панели инструментов, то в окне всплывающей подсказки для пункта меню Run To Cursor отображается текст "Step To Cursor" (Шаг к курсору). Просто игнорируйте эту подсказку (т. к. кнопка все еще выполняет команду Run To Cursor). Вы просто видите "маленькую ошибку".

VB IDE пытается сделать отладку быстрее, компилируя только часть приложения, достаточную для передачи в отладчик. Хотя идея выглядит нормально, проблема состоит в том, что в ходе отладки приложения можно "нарваться" на секцию кода, которая не была откомпилирована, и сеанс отладки будет неожиданно остановлен с сообщением о синтаксической ошибке. К тому же, это может произойти в тот момент, когда та единственная ошибка, которая сводила вас с ума, уже почти дублирована. Согласитесь, это будет неприятно.

Для того чтобы избежать каких-либо синтаксических сюрпризов, начинайте сеанс отладки командой Start With Fall Compile, Я даже добавил кнопку этой команды в панель инструментов Debug. Также выключайте режим Compile On Demand на вкладке General диалогового окна Options. Если вы работаете с большим приложением, то это увеличит время начального запуска отладки, но, по крайней мере, застрахует от обнаружения синтаксической ошибки в середине сеанса отладки.

Групповые проекты как способ перехода к отладке

В Visual Basic 5 была введена концепция группового проекта. Групповой проект позволяет разместить все ActiveX-компоненты вместе с их тестовым окружением и главный ЕХЕ-файл (при условии, что его программа написана на языке Visual Basic) в одном проекте. Если все компоненты помещены в один проект, становится возможным пошаговое выполнение ЕХЕ-файла с проходом через все элементы управления и библиотеки DLL. В качестве примера просмотрите файл TESTER.VBG (часть кода из главы 13) на сопровождающем компакт-диске.

Как было сказано выше (в разделе "Р-код Visual Basic" этой главы), Visual Basic может отлаживать объекты только на уровне интерпретируемого р-ко-да. В современном мире СОМ+-технологий и компонентных служб (Component Services) можно выполнять отладку объектов с помощью отладчика Visual Basic, но большая часть документации содержит настойчивые рекомендации выполнять отладку объектов Visual Basic на компилируемом уровне средствами отладчика Visual C++.

Для приложений компонентных служб1 я следовал рекомендациям, перечисленным в файле READMEVB.HTM системы Visual Basic 6, установленной как часть Visual Studio. Раздел "Building and Debugging MTS Components in Visual Basic 6" (Построение и отладка МТ82-компонентов в Visual Basic 6) этого документа точно сообщает, что нужно делать, чтобы отладить приложения. Сведения об отладке приложений СОМ+ можно найти в MSDN в следующих темах из Platform SDK: "Debugging Components Written in Visual Basic" (Отладка компонентов, написанных на Visual Basic) и "СОМ+ Visual Basic Debugging Support Contrasted with MTS" (Поддержка Visual Basic-отладки компонентов COM+ в сопоставлении с компонентами MTS).

Приложения компонентных служб (от англ. Component Services applications). — Пер.

Чтобы полностью отладить какую-нибудь компонентную службу или СОМ-объекты, я просто компилирую объекты и использую либо отладчик SoftICE, либо отладчик Visual C++. Отладка компилируемого кода Visual Basic нелегка, но задачу можно упростить, увеличив количество операторов трассировки, для того чтобы просматривать все переменные и другую необходимую информацию. Итак, лучше все-таки отлаживать компонентные службы и приложения СОМ+ как компилируемые приложения (вместо работы в условиях ограничений VB-отладчика).

В этой главе представлен краткий обзор различных свойств и проблем, относящихся к отладчику Visual Basic. Понимая ограничения отладочной среды Visual Basic и, прежде всего, тот факт, что отладчик воспринимает только интерпретируемый р-код и выполняет подчиненный отладчик внутри того же самого адресного пространства, программист может лучше приспосабливаться к этим требованиям. Чтобы надлежащим образом отлаживать возникающие ошибки, следует установить специальный режим перехвата ошибок (его выбор зависит от того, что вы собираетесь отлаживать). Наиболее полезными частями отладчика являются окна Immediate и Watch. Если приложение может быть полностью отлажено только средствами отладчика Visual Basic, то необходимо ознакомиться с этими окнами, потому что они позволяют значительно ускорить отладку.

Как видите, отладчик Visual Basic довольно противоречив; некоторые части отладчика чрезвычайно помогают программисту, тогда как другие являются источниками довольно серьезных проблем. Visual Basic дал возможность разрабатывать Windows-приложения быстрее, чем когда-либо прежде. К сожалению, слабости VB-отладчика пока довольно существенны.

Знаете ли Вы, что объектно-ориентированное сборочное программирование - это разновидность сборочного программирования:
- основанная на методологии объектно-ориентированного программирования; и
- предполагающая распространение библиотек классов в виде исходного кода (obj) или упаковку классов в динамически компонуемую библиотеку (dll).