В Delphi: как пропустить разделы кода при отладке?
Я часто случайно захожу в код, который меня не интересует, при отладке в Delphi.
Начнем с того, что я знаю, что вы можете перешагнуть с помощью F8, и что вы можете добраться до определенной линии с помощью f4.
Пример:
function TMyClass.DoStuff():Integer;
begin
// do some stuff
bla();
end;
procedure TMyClass.Foo()
begin
if DoStuff()=0 then // press F7 when entering this line
beep;
end;
Пример: я хочу войти в метод DoStuff (), нажав F7, но вместо того, чтобы идти туда, я сначала попадаю в FastMM4.FastGetMem (), который представляет собой массивный блок ассемблерного кода, который, очевидно, меня не интересует в момент.
Есть несколько способов сделать это, и мне не нравится ни один из них:
Добавить точку останова на "бла" (почти бесполезно, если вы хотите войти в DoStuff только в особых случаях, например, итерация 23498938);
Вместо нажатия F7 вручную переместите курсор на «бла» и нажмите F4 (работает для этого простого примера. На практике это не так);
В случае FastMM: временно отключить fastmm;
Есть ли способ намекнуть IDE, что я никогда заинтересован в переходе к определенному блоку кода, или мне всегда нужно устанавливать дополнительные точки останова или использовать F4, чтобы попытаться избежать этого?
Я надеюсь на какую-нибудь волшебную директиву компилятора вроде {$ NODEBUG BEGIN / END} или что-то в этом роде.
В большинстве случаев возможность исключать целые единицы была бы для меня достаточно детальной, но возможность избегать определенных методов или даже строк кода была бы еще лучше.
Обновление: возможно, codegear должен ввести что-то вроде пропускные пункты (в отличие от точек останова) :-)
Ответы 8
AFAIK, отладчик знает только о файлах в пути просмотра, которые вы можете изменить в параметрах. Поэтому, если вы исключите пути модулей, отладка которых вас не интересует, это даст эффект того, что вы хотите сделать.
Одно предостережение: завершение кода также зависит от пути просмотра, поэтому вы можете столкнуться с ситуациями, когда завершение кода не выполняется, когда это необходимо.
Нет. Я не верю, что есть способ сказать отладчику никогда не останавливаться на определенном участке кода. Магической директивы нет.
Лучшее, что вы можете сделать, когда попадаете в рутину, в которой не хотите участвовать, - это использовать Shift + F8, которая будет работать до возврата. Затем нажмите F7 или F8, чтобы выйти из процедуры.
Хм. Теперь я вижу ответ Мэйсона. Кое-что узнал. Спасибо, Мейсон. +1
Используйте предварительно скомпилированный неотладочный DCU FasmMM
Хотя это не прямой ответ на ваш вопрос, вы можете изменить свое первое предложенное решение, поместив точку останова на bla, которая включается только тогда, когда точка останова на Foo передана (или какое-либо другое условие по вашему выбору, например, количество итераций). Тогда он сломается только тогда, когда вы этого захотите.
Кстати, я все чаще и чаще обнаруживаю, что не останавливаю выполнение в точках останова, а скорее сбрасываю значения переменных или дампы стека в журнал сообщений. Это позволяет проводить более тщательный анализ, чем проверка переменных на лету и т. д. FWIW.
Есть «волшебный переключатель nodebug». {$ D-} отключит создание отладочного кода. Поместите это в верхней части вашего устройства FastMM, и вы не будете отслеживать его. И если вы все-таки попадете в функцию, в которой не хотите участвовать, SHIFT-F8 вытащит вас очень быстро. (ПРЕДУПРЕЖДЕНИЕ: Не используйте SHIFT-F8 внутри подпрограммы ассемблерного кода, которая играет со стеком. Это может привести к непредсказуемому поведению. Вместо этого нажмите F4 внизу.)
Что касается FastMM4: отчеты об утечках по-прежнему работают, пока у вас нет {$ define RequireDebugInfoForLeakReporting}, который по умолчанию не определен.
Вы, сэр, насколько я понимаю, сегодня выиграли Интернет. Работал красиво. Огромное спасибо.
Если вы перескакиваете в код FastMM, значит, происходят операции с памятью. В показанном вами коде нет операций с памятью, поэтому ваш вопрос неполный. Я попытаюсь угадать, что вы имели в виду.
Когда подпрограмма имеет локальные переменные типов, управляемых компилятором (например, строки, интерфейсы или динамические массивы), пролог функции должен выполнить нетривиальную работу. В прологе также настраиваются счетчики ссылок входных параметров. Отладчик представляет собой пролог в строке функции begin. Если текущая точка выполнения - эта строка, и вы «входите» в нее, вы попадете в код RTL для управления специальными типами. (Я бы тоже не ожидал, что FastMM будет там задействован, но, возможно, кое-что изменилось по сравнению с тем, к чему я привык.) В этой ситуации можно легко «перешагнуть» линию begin, а не войти в нее; используйте F8.
Если вы действительно нажимаете F7, когда входящий ваша выделенная строка, то вы делаете это неправильно. Это входит в строку begin, нет - в строку, в которой вызывается DoStuff. Итак, попадете ли вы в код FastMM, это не имеет ничего общего с реализацией DoStuff. Чтобы отладить вызов DoStuff, текущая точка выполнения уже должна быть строки с вызовом на ней.
Если вы хотите отлаживать DoStuff только на итерации 23498938, вы можете установить условная точка останова в этой функции. Щелкните промежуток, чтобы создать обычную точку останова, а затем щелкните ее правой кнопкой мыши, чтобы отобразить ее свойства. Там вы можете определить условие, которое будет оцениваться каждый раз, когда выполнение достигает этой точки. Отладчик остановится на этом только тогда, когда условие истинно. Нажмите F8, чтобы «перешагнуть» вызов DoStuff, и, если условие истинно, отладчик остановится на этом, как если бы вы вместо этого нажали F7.
Вы можете переключить опцию «использовать отладочные DCU», чтобы избежать перехода в большинство модулей RTL и VCL. Не знаю, входит ли FastMM в этот набор. Ключевое различие заключается в том, были ли скомпилированы DCU, с которыми вы связались, с отладочной информацией. Этот параметр изменяет путь к библиотеке, чтобы включить или исключить подкаталог, в котором находятся отладочные DCU. I считать вы можете настроить набор включенных или исключенных каталогов отладки так, чтобы настраиваемый набор каталогов добавлялся или удалялся на основе параметра «debug DCUs».
Вернемся к точкам останова. Вы можете настроить группы точек останова, присвоив имена вашим точкам останова. Вы можете использовать расширенную точку останова для включения или отключения именованной группы точек останова при ее прохождении. (Группы точек останова могут иметь только одну точку останова, если хотите.) Так, например, если вы хотите прервать работу только в местоположении X, если вы также передали другое местоположение Y в своей программе, вы можете установить отключенную точку останова в X и неразрывная точка останова в Y. Установите параметр «enable groups» в Y, чтобы включить группу X.
Вы также можете использовать отключенные точки останова без автоматического включения и отключения. Ваши точки останова отображаются в окне отладчика «точки останова». Если вы проходите через DoStuff и решили, что на этот раз хотите проверить bla, перейдите в окно точки останова и включите точку останова на bla. Нет необходимости переходить к реализации bla, чтобы установить там точку останова.
Дополнительные сведения о расширенных точках останова см. В Использование неразрывных точек останова в Delphi и в статье Кэри Дженсена, опубликованной несколько лет назад.
>> ... таким образом, пользовательский набор каталогов добавляется или удаляется в зависимости от настройки "debug DCUs". << Да. Мне это никогда не приходило в голову. Я только что добавил исходники DevEx в путь Debug DCU - и вуаля: больше не нужно вручную редактировать путь поиска проекта.
Вы правы, пример слабый, потому что проблема, связанная с FastMM, там не возникнет. Я сомневался, принимать ли этот ответ или ответ Мэйсона. Этот ответ полон интересной информации и советов, но ответ Мейсона сразу решает проблему.
Возможно, я что-то пропустил в вашем сообщении, но с FastMM4 вы можете отредактировать файл включения FastMM4Options.Inc и удалить '.' из следующего определения:
Из FastMM4Options.inc ****
{Включите этот параметр, чтобы запретить создание отладочной информации для Блок FastMM4.pas. Это предотвратит включение встроенного отладчика в код диспетчера памяти.}
{$ .define NoDebugInfo}
При перекомпиляции (может потребоваться сборка) отладчик больше (не должен) отлаживать код FastMM.
(+1) Хотя fastmm использовался только в качестве примера, я думаю, что ваше предложение - лучший способ позаботиться о fastmm4 .. Как-то было неправильно изменять fastmm4.pas;
В файле проекта dpr я использую
uses
{$IFNDEF DEBUG} FastMM4, {$ENDIF}
... // other units
исключить FastMM4 в режиме отладки. Не требует изменений в FastMM4, поэтому мне не нужно помнить о добавлении {$ D-} в FastMM при переходе на другую версию.
Отлично! Он работает именно так, как я хочу: отладчик больше не вмешивается в него, но при этом получает завершение кода и может видеть и изменять код с отключенной отладкой, если я хочу.