ADD_TRACE F

Bonjour,

J'ai un programme plutôt complexe en cours, et pour se faire, en dehors des autres outils, j'ai utilisé TRACE_ON.

A partir de là j'ai fait un programme qui facilite la lecture des données recueilli par le fichier généré. Là je me dis qu'il serait bien de pouvoir ajouter au fichier au moment voulu des informations pour montrer le contenu des variables.

Je pense qu'il doit être simple d'avoir une variable du genre ADD_TRACE texte ou autre.

Je donne pour info une vision de ce que traduit le programme:

Code:

13/04/2018|13:51:03->line=712
13/04/2018|13:51:03->line=713
13/04/2018|13:51:03->line=714
13/04/2018|13:51:03->line=717
13/04/2018|13:51:03->line=718
13/04/2018|13:51:03->line=719
13/04/2018|13:51:03->line=2328
13/04/2018|13:51:03->line=2329
13/04/2018|13:51:03->line=2330
13/04/2018|13:51:03->line=2358
13/04/2018|13:51:03->line=2359
13/04/2018|13:51:03->line=2360
13/04/2018|13:51:03->line=2362
13/04/2018|13:51:03->line=2402
13/04/2018|13:51:03->line=2402
13/04/2018|13:51:03->line=2403
13/04/2018|13:51:03->line=2403
13/04/2018|13:51:03->line=2404

et le résultat:



Dans ce exemple, le programme ajoute le nom des sous-programme duquel il est issu, ainsi que les commentaire et ce qui fait la structure du fichier, ce qui est représenté par la non représentation des lignes, celles qui sont en marge.

Ce serait vraiment un plus, et je pense que cela doit-être facile à programmer.

Je suis tout à fait pour cette proposition. Cela permettra d'avoir une trace nettement plus facile à interpréter.

Merci Klaus pour ton soutient.

Le programme que j'ai fait , je peux le partager si cela vous semble intéressant. Mais pour l'instant je teste des améliorations éventuelles, et j'aurai aimé mettre de la couleur.

Mais pour cela je fait un programme bien complexe, et je me bat entre windows qui impose sa loi, et Panoramic qui parfois fait des siennes sans savoir pourquoi. J'ai un soupçon mais il est dommage que l'on ne puisse ajouter une variable dans le fichier trace. C'est bien dommage, car j'arrive à afficher une page stylée sur un picture en 1/2 seconde. Le but est non seulement de taper du texte, un peu comme un Wordpad, mais surtout, de pouvoir faire des fiches de style en programmant comme on pouvait le faire avant sur les anciens systèmes sur une ligne. Oui c'est pas le sujet.

Bonjour,
Je ne vais pas ouvrir un nouveau sujet, d'autant que la demande que j'ai faite est venu à cause du problème que je constatais. En plus personne n'interviendra plus pour ce sujet.

Voici le problème:
Afin de pouvoir identifier, surtout pour que le programme ne se ferme pas, j'ai fais une sub d'erreur, la voici:

Code:

error:
 file_save trace%,"Z:\TRACE\fichier_erreur.txt"
 message "arrété"
 end
return

Tout simple, mais voila, Panoramic a stoppé avec un message d'erreur de dim déjà déclaré au début du programme.

J'avais donc "TRONnais" le déroulement du programme, ainsi qu'une liste de renseignement sur le déroulement et le contenu des variables. Il n'y a vraiment rien à redire à ce que j'ai vu, mais cela ne signifie pas que j'ai raison. Mais j'ai constaté une chose : il y a blocage alors que je ne fais rien, simplement sur une attente d'évènement. Çà c'est curieux, car je n'ai eu aucun message alors qu'une sub d'erreur existe.

Ensuite j'ai constaté une chose: et ce n'est pas seulement pour ce programme, c'est que lorsque j'ai un message d'erreur, mais qu'au lieu d'y répondre de suite, j'essaye de regarder le contenu de mes listes, et voilà au bout disons une dizaine de secondes apparait le message d'erreur de Windows comme quoi Panoramic a cessé de fonctionner.

Je serais curieux de savoir si vous avez constaté le même problème.

Au fil de mes constatations, j'ai l'impression que Windows interprète des évènements sur des attentes, et qu'au bout d'un certain temps, je pourrai penser qu'il est au bout de la pile. Je ne sais pas si Number_events a une signification ici, est-ce que cette instruction est codé pour les dlls, ou pour autre chose, toujours est-il qu'à chaque fois elle m'indique 0.

J'ai gardé le fichier trace mais décodé tel qu'on le voit plus haut, si des fois Jack voulais voir de près. Je ne pourrai pas mettre mon programme, car il y a trop de contrainte, et il faut suivre une procédure. Est-ce que je suis le seul a avoir constaté qu'une attente pour répondre à un message d'erreur, Windows  déclenchait une erreur ensuite?

EDIT: c'est toujours sur un return que se produit l'erreur

Je ne sais pas trop ce que tu veux faire, mais ton sousprogramme contient une anomalie:

Code:

error:
 file_save trace%,"Z:\TRACE\fichier_erreur.txt"
 message "arrété"
 end : ' <=============
return

La commande END n'a rien )à faire ici. D'une part, le RETURN suivant ne sera jamais exécuté. Puis, sur le fond: END est utilisé pour "rendre la main" à Windows, à la fin de la partie principale du programme, celle qui démarre directement lorsque tu lances le programme. Si tu utilises cette commande n'impoirte où dans le programme, et qui plus est, à l'intérieur d'un sousprogamme, tu perturbes complètement la gestion de la pile des adresses de retour de Panoramic. Pas étonnant que le résultat soit un plantage totalement "inexpliquable".

Pour moi, soit tu supprimes cette ligne END, soit tu la remplaces par TERMINATE. Mais END est un contre-sens ici.

Désolé Klaus, pas du tout d'accord avec toi. La commande END à la place de terminate ou stop, me permet de reprendre la main, et de pouvoir lire les lists ou memo, ce que ne permet pas les autres commandes qui ferme le programme sans pouvoir voir quoi que ce soi. Il ne s'agit pas pour moi de continuer pour que l'erreur soit ignorer, mais surtout pour qu'elle raison il y a une erreur. Un programme qui a une erreur, et qu'on fait comme si elle n'existe pas ne me convient pas. Le END tu peux le mettre n'importe où. Si tu as une boucle qui ne se termine pas, et que tu mets stop ou message, tu n'as pas la main pour voir le contenu des informations qui sont hors de vue dans un objet.

Je me souviens il y a longtemps quant on avait beaucoup moins de commandes qu'aujourd'hui, et qu'on ne savait pas comment arrêter un programme pour entrer une information, le end permettait de stopper le programme pour entrer les infos, puis de repartir ensuite en cliquant sur un bouton. Heureusement Panoramic a évolué depuis.

Je rajoute, car j'ai oublié de le dire, c'est que lorsque le message d'erreur intervient, ce n'est pas Panoramic qui le fait, sinon, j'aurai eu le message "arrété" normalement, mais que c'est Windows qui agit. Ce qui fait que le sous-programme en question n'est pas la cause, surtout que je l'ai ajouté cet après-midi pour comprendre. Mais j'ai rencontre cette erreur régulièrement sans ce supplément.

Citation :

le end permettait de stopper le programme pour entrer les infos, puis de repartir ensuite en cliquant sur un bouton

Non. Ca ne marche pas comme ça. Si tu fais END, l'adresse de retour de ta subroutine reste empilée au niveau de la pile de Panoramic, puisque le RETURN n'est pas exécuté. A partir de là, toute la gestion des adresses de retour est caduque, et il y aura fatalement un problème à un moment ou un autre. Tu ne peux tout simplement pas faire cela. Si tu essaies de relancer le traitement par le clic sur un bouton, Panoramic lance un nouveau sousprogramme (celui paramétré pour ON_CLICK du bouton), tout en gardant ton ancienne adresse de retour sur la pile. Le RETURN de ta routine ON_CLICK ne fait que dépiler sa propre adresse de retour, pas la précédente.

Je vois Klaus que je m'explique mal. Dans le cas de l'erreur, je me branche pour dire qu'il y a une erreur. Le but du END n'est pas de continuer, mais de stopper, en laissant la/les fenêtres ouvertes pour contrôler. Pour moi que le programme continu ou pas ne m'intéresse pas, ce que je cherche c'est de lire le contenu des listes ou memos où j'ai stocké  des informations. Que le programme continu n'a plus d'importance, je veux seulement vérifier les contenus. Ceci n'est pas possible avec terminate car le programme est fermé. Ce n'est pas possible avec stop, car si je stoppe, le programme se ferme aussi. Si je veux continuer (ce que je ne veux pas faire, puisse ce qui m'intéresse est de savoir pourquoi il y a erreur (et ce n'est pas le END, vu que celui-ci n'est vu qu'une fois que le branchement à l'erreur est vu).

Aujourd'hui je ne sais pas si on peux continuer à programmer en stoppant avec un END, vu qu'on peut faire autrement. Pour ce qui est de la pile des return, peut-être que Jack a programmé le vidage de la pile des événements avec la commande END, mais je m'en fout, c'est pas ce que je recherche, et je ne veux même pas le savoir. En tout cas, cela a auparavant fonctionné, mais nos programmes étaient modeste.

Bonne nuit Klaus.