Discussion :

[Nico27180]

Il s'agit de surcharger la fonction FinProgramme() de Windev.

Le but du jeu est que le programme stoppe son exécution quand on est en mode débuggage et qu'il s'arrête pour de bon quand on est en mode exécutable. L'intérêt de stopper (et non d'arrêter) le programme en débuggage c'est de pouvoir reprendre la main pour remonter la pile des appels, vérifier le contenu des variables ... et donc débugger plus facilement en étant dans le contexte.

Afficher systématiquemet la pile des appels lors d'un message de terminaison permet d'obtenir des informations complémentaire bien pratiques lors d'un crash en clientèle. Pour aller plus loin il serait également possible d'envoyer ce compte-rendu par email ou de le déposer sur un site.

Cet exemple permet aussi d'illustrer la manière dont on peut surcharger les fonctions natives, notamment grace au préfixe WL.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
PROCEDURE FinProgramme(*)
 
i est un entier 
cChaineMessage est une chaîne
 
POUR  i = 1 _A_ MesParamètres..Occurrence<div style="margin-left:40px">
   cChaineMessage += MesParamètres[i] + RC</div>FIN
 
Erreur(cChaineMessage + RC + "Pile des appels :" + RC + dbgInfo(dbgPile))	
 
SI   EnModeTest() ALORS
   STOP
SINON
   WL.FinProgramme()
FIN

http://conseilsetastuceswindev.webnode.fr

[Atsibat]

Bonjour,

je ne comprends pas la différence avec l'affichage du debogueur?
La pile me semble déjà affiché (voir capture)
Et il est quand même plus simple de mettre des points d'arrêt avec le debogueurque de faire des appels à une méthode tout au long du code...
septique donc sur ce coup là...
Enfin septique en attendant un complément peut être.

[Nico27180]

Bonjour,

Effectivement mettre des point d'arrêts permet de debugger.

Mais imaginons le cas suivant :

On code une boucle avec N itérations. A l'intérieur de chaque itération une petite usine à gaz remplie de SELON et de SI.

On lance le traitement ... et après X tours dans la boucle ça s'arrête parce qu'on tombe sur un FinProgramme correspondant à un cas non géré.

Alors le programme stoppe et vous permet ainsi d'avoir tout sous la main (pile, variables) en mode débuggage tout en étant dans le contexte.

Pas la peine de mettre ou remettre des points d'arrêt partout.

J'espère que mon explication vous convient.


http://conseilsetastuceswindev.webnode.fr/