Давно мучаюсь с непредсказуемым поведением отладчика. Он останавливается в нескольких местах кода, которые не являются breakpoints. Поведение стабильное, то есть остановки в одних и тех же местах при каждом запуске. Но при внесении изменений в код (у меня только prg) эти места меняются. Если удалить все реальные breakpoints, то лишних остановок не происходит.
Сегодня прижало - он решил останавливаться в часто вызываемой процедуре.
Можно ли от этого избавиться?

дибаггер останавливается только там, где ему зададут

периодически чисти в debug все точки останова и никаких лишних остановок не будет
если при отладке программы нужно останавливаться в определенных точках программы, используй SET STEP ON в коде

>Если удалить все реальные breakpoints
какое условие ты задаешь, как точку останова?

Если бы

Цитата:

дибаггер останавливается только там, где ему зададут

то проблемы не было.
Каждый breakpoint я ставлю по F9. Удаляю все в диалоге breakpoints через Clear All

Вот еще наблюдение.
Лишняя остановка происходила на строке
При этом перемещение этой строки в начало DO CASE или в конец не помогало - остановка происходила в новом месте. После замены литерала 'vtree-flip-agent' на 'vtree-flip-agnt' отладчик перестал останавливаться.

После обратной замены проблема возобновилась!

Может он на agent реагирует?





Исправлено 2 раз(а). Последнее : kvichans, 28.07.06 11:58

> Каждый breakpoint я ставлю по F9
> Но при внесении изменений в код (у меня только prg) эти места меняются.
тогда все понятно. По F9 ставится точка останова на номер строки в коде - это видно в списке точек останова дибаггера. При добавлении или удалении записей точка останова будет плавать

В твоем сучае я бы рекомендовал в нужном месте программы ставить SET STEP ON, в этом случае прога будет останавливаться (с выводом дибаггера) именно там, где стоит команда, даже если ты поменяешь половину кода

Странно что никто не пользуется командой ASSERT, или готовить ее не умеете

piva, спасибо за команду, не знал. Хотя, это же самое можно сделать и через интерфейс дибаггера.

но все же есть разница, когда тебе надо отловить изменение параметра или просто протрассировать участок кода

2 AlexSSS
Уточняю: точки поставленные по F9 ведут себя прилично и никуда не перемещаются

2 piva
Поясните, какое отношение имеет ASSERT к моей проблеме

Такое - что не надо ставить точек останова, если выражение ASSERT ложно - фокс сам предложит начать отладку с это строки кода

Да мне в приципе хватает вывод на экран каких-то сообщений или в Debug Out - я трассировкой СВОЕГО кода не пользуюсь, я же знаю чего я пишу , если тока в чужом копаться

по Ф9?
че-то у меня так ничего непроисходит.... и ставлю Бреакпоинты даблкликом на левом поле (красные точки такие). Но с ними у меня бывали обратные проблемы они наоборот не всегда тормозят... впрочем это было давно

Ассертом я пользуюсь... есть свои плюсы. Основной - то что они не работают в ЕХЕшнике))

Закрадывается подозрение, что ни у кого другого отладчик так себя не ведет. Это печальная картина.

Или все-таки ведет?

За советы по SET STEP ON (этим я пользуюсь) и по ASSERT (знаю, не пользуюсь, так как создал себе трассировщик) всем СПАСИБО!

Da, vedet

тоже помогает...

2 saturos - спасибо, подумаю, где SUSPEND приспособить.
2 Naomi - если беда общая, то ее и пережить легче, так как есть надежда, что исправят.

Локализация проблемы и её решение находится здесь,
в соседней ветке, в теме:

Дебагер. "Невидимые" точки останова



Исправлено 12 раз(а). Последнее : meligo, 18.09.11 10:52