Discussion :

[Magnus]

Bonjour,

Lorsque je passe en mode débug je ne peux pas examiner (CTRL + F5) la valeur de certaines variables ; j'obtiens :

valeur inaccessible

Après quelques recherches, je pensais que c'était dû au fait que dans les options du projet la case "optimisation" était cochée.
Mais même lorsque je la décoche et que je recompile le projet (après avoir supprimés tous les .dcu / .exe / ...), j'obtiens ce message pour certaines variables.

Comment inspecter la valeur de ces variables ?

Merci d'avance.

[korntex5]

deux solutions

1) tu as une directive dde compilation qui traine dans le code qui réactive l'optimisation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
{$O+} {Compiler optimisations ON}

2) Si ça ne marche pas tu crée une variable bidon que tu utilise comme leure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
mavaleur:=fonctionCalcul;  //tester, tu met ton point d'arret ici
bidon:=mavaleur+1;

dans ce cas tu peux connaitre la valeur de mavaleur

[Magnus]

1) tu as une directive dde compilation qui traine dans le code qui réactive l'optimisation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
{$O+} {Compiler optimisations ON}

J'ai fait un grep sur les sources du projet et je n'ai pas d'instruction de ce genre.

2) Si ça ne marche pas tu crée une variable bidon que tu utilise comme leure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
mavaleur:=fonctionCalcul;  //tester, tu met ton point d'arret ici
bidon:=mavaleur+1;

dans ce cas tu peux connaitre la valeur de mavaleur

En fait je n'ai même pas besoin de passer par cette ruse.
J'avais déjà rencontré ce problème : je ne peux pas voir la valeur d'une variable avec CTRL + F5 ou avec l'info bulle ; mais si je sélectionne cette variable en question et que je fais ALT + F5 alors ça marche (sous réserve que dans les options du projet, la case "optimisation" soit quand même décochée).

Merci pour le coup de pouce.

[Magnus]

Je reviens avec mon problème de "valeur inaccessible" car dans les options du projet j'ai décoché l'option "optimisation" et ce qu'il y a de formidable, c'est qu'à l'exécution, l'inspecteur de variables locales signale que :

La variable 't7' est inaccessible ici du fait de l'optimisation

Ce qui est hallucinant c'est que certaines variables sont inaccessibles alors que d'autres du même type sont parfaitement accessibles.

Si vous avez une explication je suis preneur...

[korntex5]

Le fait que les variables soient accessibles ou non , n'a rien a voir avec leur type, lorsque ton débugger voit que la variable ne sera plus utilisée il la supprime purement de la liste des variables accessibles.

zieute qd même bien si tu n'as pas la directive dont je parlais plus haut, même dans ton dpr et tes composants on sait jamais....

[Magnus]

Le fait que les variables soient accessibles ou non , n'a rien a voir avec leur type, lorsque ton débugger voit que la variable ne sera plus utilisée il la supprime purement de la liste des variables accessibles.

Ok mais peux-tu m'expliquer pourquoi dans une quelconque procédure dont voici un extrait du code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
t5 := GetTickCount;
...
t12 := GetTickCount;

=> t5 est inaccessible alors que t12 est accessible ?
Ces 2 variables ne sont utilisées ni avant ces instructions, ni après.

zieute qd même bien si tu n'as pas la directive dont je parlais plus haut, même dans ton dpr et tes composants on sait jamais....

Je n'ai aucune directive de compilation de ce genre.

J'ai trouvé une solution : à chaque modification des options du projet je RECONSTRUIS le projet au lieu de compiler simplement et ça change pas mal de choses à l'exécution.

Merci quand même.

[Pedro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
t5 := GetTickCount;
...
t12 := GetTickCount;

=> t5 est inaccessible alors que t12 est accessible ?
Ces 2 variables ne sont utilisées ni avant ces instructions, ni après.

C'est justement parce qu'elles ne sont plus utilisées après qu'elles sont "supprimées" de la liste...
Sur ton breakpoint, t12 est sur le point d'être modifié et est donc accessible (si elle est initialisée) alors que t5 n'a plus aucune raison d'être, elle est donc supprimée et donc, inaccessible...

[Magnus]

Sur ton breakpoint, t12 est sur le point d'être modifié et est donc accessible (si elle est initialisée) alors que t5 n'a plus aucune raison d'être, elle est donc supprimée et donc, inaccessible...

D'accord, donc j'imagine que quelques instructions plus tard, la variable t12 devient elle aussi inaccessible.

Merci pour ces explications Pedro.

[korntex5]

en effet si tu place ton point d'arret sur t5, alors t5 n'est plus accessible mais t12 oui , et si tu le place sur t12 alors les deux sont innaccessibles...

Par contre en effet quelques fois le fait de reconstruire permet non pas d'arranger les choses mais de tout recompiler, car quelques fois malgrès certaines modif dans ton code delphi ne rcompile pas la unit et utilise la version précédent ta modif...(bug rare)

[Magnus]

bug rare

Mouais... 8)
Je veux pas lancer une ENORME polémique ni avoir à prouver mes compétences en analyse & programmation mais je rencontre de ces difficultés à utiliser correctement delphi & tous ses petits copains (dont intraweb) dans certains contextes.

Par exemple, depuis environ 8 semaines je bataille pour convertir un projet intraweb de standalone vers ISAPI, ce qui est soi-disant ultra simple mais je rencontre des messages d'erreur du style :

Le projet dllhost.exe a provoqué une classe d'exception EWebBrokerException avec le message 'Aucun module de données n'est recensé'

Bref, plus vite j'arrêterai de développer en delphi / intraweb, mieux je me porterai mais c'est un point de vue personnel.

Thanks pour l'info

[korntex5]

je connais ça je me le dit souvent et a chaque fois je m'apperçoit que c'est moi qui n'ai pas vu l'énormité de mon erreur ou plus énéralement oublit.

Dans ton cas peut être n'as tu pas bien renseigné tout les paramètres de tes composants ou les sous menus des paramètres, mais celà n'engage que moi....

[Magnus]

je connais ça je me le dit souvent et a chaque fois je m'apperçoit que c'est moi qui n'ai pas vu l'énormité de mon erreur ou plus énéralement oublit.

Dans ton cas peut être n'as tu pas bien renseigné tout les paramètres de tes composants ou les sous menus des paramètres, mais celà n'engage que moi....

C'est très certainement vrai dans mon cas aussi mais ce que je remarque c'est qu'il me faut beaucoup plus de temps pour comprendre la cause d'une erreur intraweb qu'une application en C, Perl, Java, C++, etc.

Ce qui m'énerve profondément c'est la non-information que m'apportent les messages d'erreur : "violation à l'adresse xxx dans le module yyy"

Quand en + il n'y a pas de débogueur - pour une raison que j'ignore bien sûr c'est pas faute d'avoir essayé de paramétrer - ben ça donne des dépassements de délais pour le client et du coup t'as pas envie de proposer delphi / intraweb comme solution quand on te demande de faire du développement web.

Au final, ce qui risque d'arriver c'est que je me tape toute la conversion intraweb vers PHP étant donné la souplesse de ce langage.
Le problème majeur est que l'application que je reprends compte 80 000 lignes de code donc mon boss est réticent.

Si tu veux discuter de nos méthodes de travail (histoire de nous faire progresser mutuellement) alors n'hésites pas à me contacter par mail perso, je suis prêt à écouter tout conseil.

[Pedro]

Ce qui m'énerve profondément c'est la non-information que m'apportent les messages d'erreur : "violation à l'adresse xxx dans le module yyy"

En général, celle là (la plupart du temps avec x proche de 0) est une tentative d'accès à quelque chose de non-créé
Mais même si tu ne sais pas déchiffrer ces messages, tu peux aussi utiliser le mode "pas à pas" pour cibler ton erreur...
Bref, le debugger de Delphi est très puissant contrairement à ce que tu voudrais croire... Moi il m'a systématiquement permis de trouver le(s) bug(s)...
Sans vouloir t'offenser, je pense que c'est toi qui ne t'en sers pas correctement. N'essaie pas d'appliquer les principes de debugging de VC++, c'est un peu différent... A chaque langage ses défauts... et ses qualités

[korntex5]

La violation d'accès est trèssouvent due a un objet que tu utilise qui n'est pas créé ou plus, ou alors que tu as essayé d'accéder par exemple à un élément hors d'un tableau, de sa plage, le débugger est rès puissant, fais moi confiance.

Mais il est vrai dans certains cas comme qd tu traite des application client server sur la même machine avec deux delphi tu peux parfois t'y perdre mais bien placé les points d'arret fonctionnent toujours très bien, sauf cas présent pour moi, je bidouille le journal d'évenements windows pour faire des macros et une fois passé sur mon point d'arret je perd tout les évenements du journal suivant, mais bon là on est dans la haute couture...

C sur php est plus adapté pour l'intraweb personellement même sans essai je le pense, puisque c'est sa raison d'être, mais bon c sur le "c" c'est plus rapide à apprendre c comme le vélo et delphi c'est seulement comme la navette columbia, tu peux aller beaucoup plus loin...

[Magnus]

C'est marrant de constater comment vos opinions se rejoignent.

Par contre, je me suis mal exprimé sur un point : le débogueur est (pour moi) un élément clé de tout langage de programmation.
Et c'est exactement mon problème quand je développe en mode ISAPI avec intraweb : je N'ARRIVE PAS à faire fonctionner le débogueur qui justement me permettrait de trouver mes erreurs beaucoup plus rapidement.

Ce n'est pas faute d'avoir trouvé des tutoriels proposant divers techniques mais rien n'y fait pour l'instant je n'arrive pas à le faire fonctionner dans ce contexte.

[korntex5]

C vrai que dans ton cas je n'ai jamais essayé isapi intraweb...
peut être y a t il un bug qui m'est inconnu...
Mais zieute qd même les option de delphi et du projet voir si le débuggeur n'est pas dévalidé, voir même si une directive de compilation ne l'inhibe pas...mais là je ne suis plus assez compétent....