Delphi: почему контрольные точки время от времени нельзя использовать (зеленая выделенная линия в IDE)?

Отладочная информация отсутствует в файле.

Убедитесь, что вы используете конфигурацию Debug. (Project Manager дерево, разверните Build Configurations, убедитесь, что Debug выделен полужирным шрифтом. Если это не так, щелкните правой кнопкой мыши Debug и выберите Activate в контекстном меню.) Убедитесь, что затем выполните /strong > вашего проекта, а не только Компилировать.

Если это все еще не работает, перейдите в Project->Options из главного меню IDE, нажмите Compiling в разделе Delphi Compiler и проверьте раздел Debugging в правой половине окна. Убедитесь, что отмечены Debug Information и Local Symbols. Если вы пытаетесь проследить в собственном источнике VCL, также проверьте Use debug .dcus (вы захотите отключить это и выполнить полную сборку своего проекта, как только вы закончите, так как это раздражает, повторная отладка обычно). Опять же, вы захотите построить и не скомпилировать.

Если все вышеперечисленное не удается, другая возможность заключается в том, что модуль кода, который вы открыли в Редакторе кода, не является тем же, что и компилятор. Убедитесь, что у вас нет нескольких копий файла на вашем компьютере в месте, которое может найти первый компилятор. Если вы не уверены, удалите файлы .dcu с этим именем устройства, а затем выполните сборку своего проекта и посмотрите, находится ли вновь созданный .dcu в месте, которое вы ожидаете.

Я подозреваю, что это происходит, когда вы сделали сборку релизов, при этом отладка отключена. Затем вы возвращаетесь обратно к конфигурации отладки и выполняете компиляцию, а не сборку. Файлы, в которых вы не можете установить точки останова, соответствуют файлам с DCU, созданным компиляцией с отключенным отладки.

Простое создание для повторного создания всех файлов DCU заставит ваши точки останова работать снова.

У меня была такая же проблема с XE4. Вот почему я нашел эту статью пару часов назад. Ни один из вышеперечисленных решений не работал у меня. Правильное решение для меня - до сих пор - было добавление опции "удаленные отладочные символы". Странно, потому что я не использую удаленную отладку. В любом случае, теперь это выглядит нормально.

Вот еще одна причина, по которой код не совпадает с маркерами точек останова (сине-красная "таблетка" в желобе).

Редактор распознает три разных окончания строки,

• CRLF (возврат каретки - пара перевода строки)
• Только CR
• Только LF

Из них CRLF является значением по умолчанию в редакторе.

Однако компилятор, похоже, не рассматривает CR only как конец строки, только только CRLF и LF only. Таким образом, если ваш исходный файл имеет только один или несколько CR only, "синие таблетки" будут смещены относительно источника.

Вы, возможно, получили исходные файлы с символом CR only EOL (конец строки), например, из Интернета. Я помню, MAC OS использовала CR only как EOL.

Чтобы проверить EOL в вашем файле, вы можете включить отображение EOL в редакторе

( Tools - Options - Editor options - Source options - Show line breaks).

Символы выглядят странно (см. Изображения ниже), но это просто C сверху L для CRLF, C сверху R для CR и L сверху F для LF.

На следующих изображениях показаны обычные EOL (CRLF) и EOLS после того, как я принудительно установил CR only для одной строки и LF only для другой строки в шестнадцатеричном редакторе. Как было сказано выше, CR only смещает маркеры точки останова из исходного кода.

Обычные CRLF EOL's:

Одна строка CR only с CR only и одна LF only с LF only:

исправлять
Чтобы сбросить все EOL в CRLF, снимите флажок Preserve line ends в Editor Options

( Tools - Options - Editor options),

внести тривиальное изменение, чтобы файл был помечен как измененный, рядом с файлом, чтобы сохранить изменения в XYZ.pas? YES и снова откройте.
Теперь все окончания строки - CRLF.

Это ошибка, перезапуск Delphi устранит вашу проблему.

Включение удаленных отладочных символов сделало это для меня (ничего более не работало). Проект > Параметры > Связывание и проверка Включите удаленные отладочные символы.

Другая причина неработоспособности точки останова может быть (часто тестируется с delphi5):
Слишком много процедур в блоке.
Решение состоит в том, чтобы переместить процедуры в другую единицу.

У меня была связанная с этим проблема: я потерял точки останова в определенном файле, но другие файлы были в порядке. Случилось так, что я переименовал этот файл, но мне неизвестно, что DCU для старого файла все еще используется, потому что он упоминается в предложении "uses" где-то.

Решение состоит в том, чтобы вручную удалить все DCU (сделать "чистый" недостаточно, потому что старый файл, представленный DCU, больше не находится в проекте) и перестроить. Вы получите ошибку компиляции, показывающую плохие предложения "uses".

В delphi 7, похоже, существует реальная ошибка при установке точек останова.

У меня была единица, где многие тексты были определены в

const constname: array [0..x] типа record = (...);

в разделе интерфейса, где тип записи имеет некоторые элементы AnsiString. В разделе реализации есть несколько процедур.

В некоторых частных случаях, когда я устанавливаю точку останова в любой части процедуры, delphi не останавливается на ней!

Замечания: все параметры для отладки установлены правильно (как для F7 вызывает остановку delphi в "начале" программы, синие точки видны во всем блоке, когда линия остается красной при выполнении приложения) и все DCU, которые имеют в соответствии с файлами PAS были удалены со всех моих дисков и во всех папках, прежде чем я сделал полную сборку для всего проекта. Поэтому ни один файл wold не должен никуда болтаться. Для тестирования я переименовал PAS в другое имя, которое никогда не использовалось ранее, и, конечно же, нигде на каком-либо диске, затем не адаптировало все источники и не перекомпилировало, просто чтобы убедиться, что мы с delphi ищем один и тот же файл PAS, но точки останова тоже не работает.

Но произошло другое, очень странное: текст consts (!) изменен в моем исполняемом файле (не в файле exe, но, очевидно, в памяти)! Эти тексты были проверены на правильность во время запуска программы, а иногда и жаловались на ошибки! Отображение текстов в окне сообщений показало, что в этих текстах был изменен символ sinlge, который определяется как const. Для теста я попытался присвоить что-то этим константам в моем коде, но, как и ожидалось, компилятор жаловался, поэтому он не может быть обычным назначением, которое вызывает изменение текста. Должен быть неправильный указатель. Weird.

Итак, часы тестирования последовали за ним, ища какой-либо исходный код, который мог бы установить неправильный указатель, который позже может вызвать это изменение в текстовом const. Я поместил блок сообщений в секцию инициализации первого блока в цепочке инициализации блока, которую я смог отредактировать, но измененный char был уже там! Должно быть изменено очень рано во время запуска моего приложения, тогда!

Наконец, я понял, что char, который появился в моих текстах, всегда был $CC - это именно код ассемблера для INT 3, код, который delphi использует для установки точки останова. И при перемещении точки останова внутри этого устройства линия вверх или вниз, положение измененного символа также перемещает некоторые символы слева или справа! И количество символов, которые некорректно перемещали, просто коррелировало с предполагаемым количеством ассемблерных закодированных байтов соответствующих строк. Установив две точки останова в линиях рядом друг с другом, внезапно изменились два символа! При удалении всех точек останова с этого блока текст остается неизменным!

Итак, есть только один вывод: сам дельфи меняет эти тексты при попытке установить точку останова и не может этого сделать. Я не смог избавиться от этой ошибки. Ни один из советов о повторной синхронизации delphi внутренней бухгалтерии файлов исходного и объектного кода не помог мне!

Поскольку рассматриваемая единица состояла главным образом из {$ I} строк между несколькими {$ IFDEF} s, для включения некоторых разных, но длинных паскальных текстов, я считал, что delphi имеет проблемы с слишком длинными включениями или оценки условных команд компилятора. Поэтому я удалил входящие и сразу же отправил исходный текст в блок и удалил {$ IFDEF} s, который скомпилирован без ошибок, но установка контрольных точек также изменила мои текстовые константы, а не прекратила выполнение. Все равно!

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

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

У меня также была такая же проблема, поэтому я пришел сюда. В дополнение к решению Дэвида Хеффернана я добавляю изображение здесь. В моем случае это было очень просто. В проекте explorer это был Release, когда я сменил его Debug, он работает для меня. Пожалуйста, посмотрите на изображение.

Спасибо Счастливое кодирование Икбал

Есть хорошие советы выше. Но, возможно, вы пытаетесь отладить код, который не используется в проекте.

Я проверял MSBuild в Delphi Compile (мы делаем MS Builds). Это мешало работе контрольных точек. Не проверено, и это работает.

Бит позднего ответа, но я тоже наткнулся на эту проблему.

Если я активировал MyPackage.bpl(жирный шрифт) в менеджере проектов с конфигурацией отладки, затем скомпилировал его, я увидел, что IDE зарегистрировала отладочную информацию (синие точки слева от редактора).

Но когда я активировал свой файл MainProject.exe(тот, который использует MyPackage.bpl), эти синие точки исчезнут, указывая, что отладочная информация больше не присутствует. После некоторой царапины на голове я понял, что настроил зависимость (щелкните правой кнопкой мыши на MainProject.exe → Dependencies) в конфигурации Release MyPackage.bpl, а не на настройке Debug.

Каждый раз, когда я скомпилировал MyProject.exe, он ссылался бы на конфигурацию Release, а не на конфигурацию отладки!

Итак, проверьте конфигурацию зависимостей!

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

Используя F9 для запуска приложения, точки останова будут работать как положено. Я использую XE4, и я не знаю, исправит ли это предыдущие версии Delphi.

Если файл, который вы пытаетесь установить точки останова, является частью DLL, вам нужно сделать эту DLL активную, дважды щелкнув по ней в диспетчере проектов, чтобы она стала полужирным, а затем постройте ее. Затем синие круги появятся рядом с строками, где вам разрешено устанавливать точки останова.

В моем случае я устанавливал точки останова в блоке, который в то время как открытый в среде IDE не был частью активного проекта. Такие точки останова также отображаются как зеленые. IOW Я вообще не был на правильной странице.

(я обнаружил это, попробовав все вышеперечисленное.)

Кажется, никто не упомянул, что в Delphi 2010 (еще не пробовали другие версии) контрольные точки, установленные в функциях с помощью директивы inline, не работают.