Delphi: pourquoi les points d'arrêt de temps en temps ne sont pas utilisables (ligne en surbrillance verte sur IDE)?
De temps en temps, je perds la fonctionnalité de point d'arrêt dans Delphi.
Je pensais que c'était un problème Delphi 2009 mais maintenant je l'ai aussi dans Delphi XE.
Dans Delphi 2009 en supprimant .fichier dproj j'ai fait fonctionner les points d'arrêt à nouveau.
Dans Delphi XE, Je ne suis pas capable de faire apparaître des breakopints. J'ai la mise à jour 1 avec tous les correctifs appliqués.
Quelqu'un a-t-il une solution?
17 réponses
Les informations de débogage ne sont pas présentes dans le fichier.
Assurez-vous que vous utilisez la configuration de Débogage. (Project Manager
arborescence, développez Build Configurations
, assurez - Debug
est en gras. Si ce n'est pas le cas, faites un clic droit sur Debug
et choisissez Activate
dans le menu contextuel. Assurez-vous que puis faire un Construire de votre projet, et pas seulement un Compiler.
Si cela ne fonctionne toujours pas, allez dans Project->Options
dans le menu principal de L'IDE, cliquez sur Compiling
sous Delphi Compiler
, et vérifiez la section Debugging
sur la moitié droite de la fenêtre. Assurez-vous que Debug Information
et Local Symbols
sont tous deux activés. Si vous essayez de tracer dans la propre source de la VCL, vérifiez également Use debug .dcus
(vous voudrez désactiver cela et faire une construction complète de votre projet dès que vous avez terminé, car cela devient ennuyeux lorsque vous déboguez normalement). Encore une fois, vous voudrez construire et ne pas compiler.
Si tout ce qui précède échoue, une autre possibilité est que l'Unité de code que vous avez ouverte dans L'éditeur de Code n'est pas la même que celle vue par le compilateur. Assurez-vous que vous n'avez pas plusieurs copies du fichier sur votre ordinateur dans un emplacement que le compilateur pourrait trouver en premier. Si vous n'êtes pas sûr, supprimer le .fichiers dcu avec ce nom d'unité, puis faire une construction de votre projet, et voir si le nouveau créé .dcu est à l'endroit que vous attendez.
J'ai trouvé un meilleur moyen.
Dans L'arborescence du Gestionnaire de projet, faites un clic droit sur le projet et choisissez "nettoyer" dans le menu contextuel.
Les points d'arrêt réapparaissent comme par magie et c'est une méthode très rapide.
Je soupçonne que cela se produit lorsque vous avez fait une version de version, avec debug désactivé. Ensuite, vous revenez à la configuration de débogage et faites une compilation plutôt qu'une construction. Les fichiers où vous ne pouvez pas définir de points d'arrêt correspondent à ceux avec DCUs produits par une compilation avec débogage désactivé.
Il suffit de faire une build pour générer à nouveau tous les fichiers DCU pour que vos points d'arrêt fonctionnent à nouveau.
J'ai eu le même problème avec XE4. C'est pourquoi j'ai trouvé cet article il y a quelques heures. Aucune des solutions ci-dessus n'a fonctionné pour moi. La solution correcte pour moi - jusqu'à présent-était d'ajouter l'option "symboles de débogage à distance". Étrange parce que je n'utilise pas le débogage à distance. Quoi qu'il en soit, il semble OK maintenant.
J'ai eu un problème connexe: j'ai perdu les points d'arrêt dans un fichier particulier, mais les autres fichiers étaient bien. Ce qui s'était passé était que j'avais renommé ce fichier, mais je ne savais pas que le DCU De l'ancien fichier était toujours utilisé car il était référencé dans une clause" uses " quelque part.
La solution consiste à supprimer manuellement tous les DCUs (faire un "nettoyage" ne suffit pas car l'ancien fichier représenté par le DCU n'est plus dans le projet) et à reconstruire. Vous obtiendrez une erreur de compilation affichage des mauvaises clauses "utilisations".
Une autre raison pour ne pas fonctionner point d'arrêt pourrait être (souvent testé avec delphi5):
Trop de procédures dans une unité.
La solution consiste à déplacer les procédures vers une autre unité
J'étais aussi confronté au même problème alors je suis venu ici. En plus de la solution David Heffernan, j'ajoute une image ici. Dans mon cas, c'était très simple. Dans l'Explorateur de projet, il était libéré quand je l'ai changé Debug, cela fonctionne pour moi. Merci de vous référer à l'image.
Merci Codage Heureux Iqbal
Dans delphi 7, Il semble y avoir un vrai bug sur la définition des points d'arrêt.
J'avais une unité où de nombreux textes sont définis dans un
Const constname: tableau[0..x] du type d'enregistrement = (...);
Dans la section interface, où record-type a quelques éléments AnsiString. Dans la section Mise en œuvre, il y a quelques procédures.
Dans certains cas particuliers, lorsque je définis un point d'arrêt n'importe où dans une procédure, delphi ne s'arrête pas là!
Remarques: toutes les options pour le débogage sont définis correctement (comme pour F7 provoque delphi arrêter au "début" du programme, les points bleus sont visibles dans toute l'unité la ligne reste rouge lors de l'exécution de l'application) et tous les DCUs qui ont des fichiers PAS selon ont été supprimés de tous mes disques et dans tous les dossiers, avant que je ne Donc, aucun fichier wold ne devrait traîner n'importe où. Pour les tests, j'ai renommé le PAS à un autre nom, jamais utilisé auparavant, et sûrement nulle part ailleurs sur un disque, puis adapté toutes les sources et recompilés, juste pour être sûr que delphi et moi regardons le même fichier PAS - mais les points d'arrêt n'ont pas fonctionné non plus.
Mais il s'est passé une autre chose très étrange: le texte consts (!) changé dans mon exécutable (pas dans le fichier exe, mais évidemment dans la mémoire)! Ces textes ont été vérifiés pour l'exactitude lors du démarrage du programme, et parfois il se plaignait d'erreurs! Affichage des textes dans une messagebox a montré, qu'il y avait changé un caractère sinlge dans que les textes, qui sont définis comme const. Pour le test, j'ai essayé d'attribuer quelque chose à qui consts dans mon code, mais, comme prévu, le compilateur s'est plaint, donc ce ne peut pas être une affectation ordinaire qui provoque le changement du texte. Ça doit être un mauvais pointeur. Étrange.
Ainsi, des heures de test ont suivi, à la recherche de tout code source qui aurait pu mettre en place un mauvais pointeur qui pourrait plus tard provoquer ce changement dans un texte const. J'ai placé la messagebox dans la section d'initialisation de la première unité à l'intérieur la chaîne d'initialisation de l'unité que j'ai pu éditer, mais le char modifié était déjà là! Doit être changé très tôt lors du démarrage de mon application, alors!
Enfin, j'ai compris que le char apparu dans mes textes était toujours un $ CC-qui est exactement le code assembleur pour INT 3, le code que delphi utilise pour définir un point d'arrêt. Et lorsque vous déplacez un point d'arrêt dans cette unité une ligne vers le haut ou vers le bas, la position du caractère modifié déplace également certains caractères à gauche ou à droite! Et le nombre de caractères que le mauvais a déplacé est juste corrélé avec la quantité estimée d'octets codés par assembleur dont les lignes concernées ont besoin. Réglage de deux points d'arrêt dans les lignes près de l'autre, tout à coup deux caractères ont changé! Lors de la suppression de tous les points d'arrêt de cette unité, le texte est resté inchangé!
Il n'y a donc qu'une seule conclusion: delphi lui-même change ces textes en essayant de définir un point d'arrêt et ne le fait pas. J'ai été incapable de se débarrasser de ce bug. Aucun des conseils sur re-synchroniser la comptabilité interne de delphi des fichiers de code source et objet m'a aidé!
Comme l'unité concernée consistait principalement en {$I} lignes entre plusieurs {$IFDEF}s, pour inclure des textes pascal différents mais longs, j'ai considéré que delphi avait des problèmes sur des inclusions trop longues ou sur l'évaluation des directives du compilateur conditionnel. J'ai donc supprimé les includes et mis le texte source immédiatement dans l'unité, et supprimé le {$IFDEF}s-qui a compilé sans erreurs, mais en définissant les points d'arrêt ont également changé mes constantes de texte, au lieu d'arrêter l'exécution. Tout de même!
J'ai résolu cela pour l'instant en divisant l'unité en deux unités, l'une contenant uniquement le texte dans sa partie interface, et l'autre pour contenir les procédures. Et maintenant, sans changer les paramètres du compilateur ni de l'éditeur de liens, tous les points d'arrêt fonctionnent comme prévu et le texte n'est plus modifié!
Donc, si les points d'arrêt ne fonctionnent pas pour vous, alors vous êtes sûr qu'ils devraient, éventuellement delphes est l' coupable et ne parvient pas à définir les points d'arrêt au bon endroit. Dans le cas où il est en train de changer quelques textes, peut-être que jamais à votre attention. Diviser l'unité m'a aidé, peut-être que ça t'aide aussi.
Activer les symboles de débogage à distance l'a fait pour moi (rien d'autre n'a fonctionné). Projet > Options > lier et vérifier inclure des symboles de débogage distants.
Il semble que personne n'a mentionné que sous Delphi 2010 (n'a pas encore essayé d'autres versions), les points d'arrêt définis dans les fonctions avec le inline
la directive ne marche pas.
Dans mon cas, je définissais des points d'arrêt dans une unité qui, bien qu'ouverte dans L'IDE, ne faisait pas partie du projet actuellement actif. Ces points d'arrêt apparaissent également en vert. Je N'étais pas du tout sur la bonne page.
(j'ai découvert cela après avoir essayé tout ce qui précède .)
Si le fichier dans lequel vous essayez de définir des points d'arrêt fait partie d'une DLL, vous devez activer cette DLL en double-cliquant dessus dans Project Manager afin qu'elle devienne en gras, puis la construire. Ensuite, les cercles bleus apparaîtront à côté des lignes où vous êtes autorisé à définir des points d'arrêt.
Désolé de faire revivre un vieux post mort... En utilisant F9 pour exécuter l'application, les points d'arrêt fonctionne comme prévu. J'utilise XE4 et je ne sais pas si cela va "réparer" les versions antérieures de Delphi.
Si le groupe de projet utilise des paquets (bpls), assurez-vous qu'aucun d'entre eux n'a d'avertissement du compilateur concernant les unités implicitement importées. Si ceux-ci existent, vous ne pourrez parcourir le code que via la fenêtre de débogage du processeur.
Réponse un peu tardive mais je suis tombé sur ce problème aussi.
Si j'ai activé le MyPackage.bpl (gras) dans le gestionnaire de projet avec la configuration de débogage, puis compilé, je pouvais voir L'IDE enregistré les informations de débogage (points bleus à gauche de l'éditeur).
Mais quand j'ai activé Mon MainProject.exe (celui qui utilise MyPackage.bpl), ces points bleus disparaîtraient, indiquant que les informations de débogage ne sont plus présentes. Après quelques grattage de la tête, j'ai réalisé que j'ai mis en place un dépendance (clic droit sur MainProject.exe - > dépendances) sur la configuration de publication de MyPackage.bpl et non sur la configuration de débogage.
Chaque fois que j'ai compilé MyProject.exe, il serait lié à la configuration de la version, pas à la configuration de débogage!
Vérifiez donc vos configurations de dépendance!
J'ai fait vérifier MSBuild sous Delphi Compile (nous faisons MS Builds). Cela empêchait les points d'arrêt de fonctionner. De manière incontrôlée, et il fonctionne.