PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Audit dynamique en mode "texte" pour une app en production
Audit dynamique en mode "texte" pour une app en production
Débuté par Jérôme, 27 sep. 2022 11:21 - 9 réponses
Membre enregistré
179 messages
Popularité : +17 (17 votes)
Posté le 27 septembre 2022 - 11:21
Bonjour,

je cherche à récupérer les messages de type "warnings" que l'on a dans la trace du débogueur après une exécution en mode test dans l'environnement Windev mais en production.

Je connais l'audit dynamique en production (par un raccourci [CTRL] + [ALT] + A, je n'ai jamais réussi à le lancer comme ça) ainsi que par un fichier (là ça fonctione) qui s'appelle la même chose que l'exe et qui contient :
[AUDIT]
ACTIF = 1
FICHIER = c:\temp\audit.waudit
OPTION = +CA+WA+WP+EA+ER+EX


De cette manière il est possible de récupérer les messages de type warnings, mais uniquement dans des conditions spécifiques :

- Il faut avoir exactement le code source (ce qui en production au bout de quelques temps n'est pas toujours le cas)
- Il faut avoir le projet ouvert sur sa machine et faire glisser le fichier d'audit, c'est faisable mais plus laborieux que d'avoir directement une sortie au format texte interprétable chez le client.

Je conçois bien la problématique de la sécurité (on pourrait utiliser ce mécanisme pour avoir des informations délicates/compromettantes sur l'application mais si on sait qu'elle est dans un environnement sécurisé, est-il possible de sortir ces infos de manière textuelles ?

Merci beaucoup pour vos réponses / idées / pistes. :merci:
Posté le 27 septembre 2022 - 12:33
Bonjour, Jérôme
Pour suivre les erreurs en temps réel, j'utilise toujours la méthode "à l'ancienne" avec :
1) Une procédure globale de gestion des erreurs
2) Un code d'appel à la gestion d'erreur dans chaque élement du projet (fenêtres, états)
3) L'interception et l'écriture des erreurs dans un fichier texte (Erreur.log)

J'y écris toutes les erreurs en exécution avec :
- Version de Windows
- Nom de l'utilisateur et du poste
- Date / Heure
- Fonction
- Procédure
- Ligne de code concernée
- Code de l'erreur

C'est assez traditionnel, mais çà fonctionne très bien. Peu de code, on arrive chez le client, on lit le fichier avec Notepad et on sait vite où il faut commencer à fouiller...
Membre enregistré
179 messages
Popularité : +17 (17 votes)
Posté le 27 septembre 2022 - 20:01
Bonjour Denis,

merci beaucoup pour cette réponse.

Pour une procédure globale de gestion des erreurs fatales, pas de soucis je vois comment faire.

Mais comment paramétrer une procédure globale qui capte les erreurs non fatales, comme ce code par exemple :

sContenu est une chaîne = fChargeTexte("c:\ce_repertoire_n_existe_pas\ce_fichier_encore_moins.txt")
ToastAffiche("Taille du contenu : "+Taille(sContenu))


Est-ce que votre mécanisme capte en production le warning (=erreur non fatale) qui est donné par la trace du débogueur en mode test ?



Membre enregistré
286 messages
Popularité : +24 (28 votes)
Posté le 28 septembre 2022 - 04:33
Bonjour Jérôme

Pourquoi ne pas tester l'existence du fichier (avant de le charger) avec la fonction suivante :
https://doc.pcsoft.fr/?3036015&verdisp=210

Bien cordialement
Message modifié, 28 septembre 2022 - 04:35
Posté le 28 septembre 2022 - 05:36
Jérôme a écrit :
Bonjour Denis,

merci beaucoup pour cette réponse.

Pour une procédure globale de gestion des erreurs fatales, pas de soucis je vois comment faire.

Mais comment paramétrer une procédure globale qui capte les erreurs non fatales, comme ce code par exemple :

sContenu est une chaîne = fChargeTexte("c:\ce_repertoire_n_existe_pas\ce_fichier_encore_moins.txt")
ToastAffiche("Taille du contenu : "+Taille(sContenu))


Est-ce que votre mécanisme capte en production le warning (=erreur non fatale) qui est donné par la trace du débogueur en mode test ?






La méthode proposée par GEMINI est la meilleure : Tester l'existence du fichier avant le fChargeTexte.

Mais, si vous voulez garder une trace dans un fichier Erreur.log, il est possible de faire aussi comme ceci...

sContenu est une chaîne ANSI
w est un entier

sContenu= fChargeTexte("c:\mon_fichier.txt")

SI sContenu = "" ALORS
//--- Boite d'affichage de l'erreur (ou pas)
Erreur(ErreurInfo())
//--- Ecriture dans le fichier LOG
w = fOuvre(Fic_Erreur,foEcriture)
fPositionne(w,-1,fpFin)
fEcritLigne(w,ErreurInfo())
fFerme(w)
FIN
Membre enregistré
179 messages
Popularité : +17 (17 votes)
Posté le 28 septembre 2022 - 10:35
Bonjour Gemini1961,

merci pour votre réponse.

Mon exemple est ici un exemple prétexte pour illustrer plus globalement ma demande.

Pour gérer ce cas précis de fChargeTexte aucun problème.

Ma demande est lorsque l'on a un fonctionnement incorrect dans une application sans avoir de message d'erreur car un warning (que l'on a pas pensé à gérer lors du développement et/ou que l'on ne pensait pas qu'elle pouvait provoquer un problème) apparait mais nous est complètement invisible en production.

Donc mon besoin est d'intercepter ces warnings (comme le fait l'audit dynamique) mais sans avoir recours à ce fichier binaire uniquement interprétable avec Windev + le code source du projet exécuté.
Posté le 29 septembre 2022 - 13:49
Je vous ai soumis un exemple, qui peut très bien être transformé en procédure globale.
L'avez-vous testé ?
Membre enregistré
179 messages
Popularité : +17 (17 votes)
Posté le 29 septembre 2022 - 15:21
Bonjour Denis,

non parce que dans votre exemple vous testez le retour du fChargeTexte.
Si le fichier existe mais est vide, le warning n'est pas généré mais on rentre quand même dans l'embranchement du SI ... ALORS
C'est précisément ce que je désire éviter car dans un code de 20'000 lignes il est long est fastidieux (et on peut louper des cas) de systématiquement tester les retours.

Ici le mécanisme de l'audit dynamique le fait (logguer les warnings sans ajout de code supplémentaire) mais génère un fichier binaire illisible si l'on a pas Windev + le code source exact associé.

A moins que je n'ai pas du tout compris votre exemple qui est en fait générique et qui fait exactement cela ?
Oserais-je vous demander de me montrer comment votre exemple transformé en procédure global intercepte tous les warnings du WLangage sans devoir toucher au code déjà mis en place ?

Merci beaucoup pour vos précisions ! :merci:
Posté le 30 septembre 2022 - 03:30
Je ne vois pas de solution à votre problématique, sinon demander à PCSoft d'inclure cette fonctionnalité particulière (qui existe déjà sous sa forme actuelle) dans une prochaine version ;)
Membre enregistré
179 messages
Popularité : +17 (17 votes)
Posté le 30 septembre 2022 - 09:47
J'ai fait une demande au ST, ils m'ont confirmé que ce n'était pas possible actuellement dans cette version et que ça a été transformé en suggestion pour une future évolution. Du coup pas de regret !
En tout cas merci beaucoup pour votre aide ! :merci: