Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
petite question pour les spécialistes.
Dans notre vieille application qui a connu de tout et de tout le monde depuis presque 10 ans nous avons deux façon de "valider" les écrans (les deux sont actives en même temps sur tous les écrans
Soit on appuie sur le touche Entrée ce qui est intercepté par un bouton en default en arrière plan sur chaque fenêtre et qui déclenche un event "ue_ok"
voici le code derrière le clicked du commandbutton
if isValid(this) then if ib_trt then return else return end if this.ib_trt = true f_vide_file() if isvalid(parent) then parent.triggerevent("ue_ok") // parent.postevent("ue_ok") end if if isValid(this) then this.ib_trt = false end if
f_vide_file est une fonction qui boucle tant que yield() renvoie true
Soit en cliquant sur un bouton dans le toolbar
Voici le code derrière le bouton
graphicobject u_obj if isvalid(w_general.getactivesheet()) then u_obj=getfocus() u_obj.triggerevent(losefocus!) w_general.getactivesheet().triggerevent("ue_ok") end if
Depuis que l'on a migré l'application en pb 12.5 (elle était avant en 10 et une partie existait déjà en 7)
Nous avons une épidémie de GPF sur certains postes (ça fonctionne correctement sur 99.9% des PC) pour certains écrans (en général les mêmes écrans dans les mêmes fonction d'un poste à l'autre)
Le GPF survient quand on clique dans la toolbar mais pas quand on appuie sur le touche Entrée.
Si on lance l'application avec le switch /PBDEBUG ça ne plante pas quel que soit le cas.
Pour le moment on s'en est sortis en identifiant l'instruction problématique.
Un getcontextservice au démarrage de l'application
Un GarbageCollect() inutile (donc supprimé) sur deux écrans
Un find sur un datastore sur un autre écran (find présent dans une fonction appelée à l'ouverture de tous les écrans pourtant), supprimé car c'était un vieux résidu qui n'était plus utilisé
Un modify datawindow pour rendre visible ou non une image en fonction d'habilitations, là le déplacement de la ligne de code (du constructor de l'objet où la dw est invisible vers l'endroit qui rend la dw visible) a réglé le soucis.
J'aimerai trouver une solution autre que le cas par cas car quand ça arrive on n'arrive pas à reproduire le problème chez nous donc en général ça veut dire immobiliser un PC à distance incriminé chez le client et faire des batteries de tests et de compilations. De plus les problème apparaissent de manière soudaine sur des écrans que l'on ne touche pas.
Je vois déjà une différence entre les deux un vide la file (celui qui marche toujours) de message l'autre non (celui qui plante parfois)
Je ne me souviens plus de pourquoi on a mis un triggerevent("ue_ok") et non un postevent("ue_ok")
On va déjà essayer en rajoutant le f_vide_file() dans le bouton de la toolbar mais je veux bien vos avis d'experts sur la chose.
Merci par avance.
Hors ligne
Salut, quand tu as un GPF, as-tu déjà essayé de voir dans quel module (EXE ou DLL) l'application s'est planté ?
Car selon la dll ca peut donner un indication; par exemple j'ai déjà eu des plantages avec des Modify et je m'en suis aperçu parce que le module était PBDWExxx.DLL, il est aussi possible de regarder la stack trace avec un debugger pour plus de précision.
Sinon, je crois me souvenir avoir fait des tests avec du PBNI pour mettre en place un hook des GPF qui affiche la stack trace PB dans les fastfuncs dans une messagebox. Evidement c'est pas super utile quand ca tombe dans du code qui à été POSTé, mais c'est déjà cà.
Hors ligne
J'ai la stack trace qui s'affiche dans la messageBox unexpected GPF et c'est systématiquement sur la ligne -1 d'un script.
D'ailleurs un petit cas rigolo:
Tous nos écrans appellent dans l'event open la fonction globale f_xxx_win
Dans cette fonction f_xxx_win nous avions un find
Dans une des fenêtres (une sur quelques centaines) de l'application nous avions un GPF à la ligne -1 de l'event close (sur une dizaine de postes sur les quelques milliers installés), GPF réglé par la suppression du find dans f_xxx_win.
Dans ce cas pas de post il suffisait d'ouvrir et de fermer la fenêtre.
Avec quoi je pourrais débuguer sur les postes des clients, sachant que:
Tout doit se faire à distance (connexion via VNC)
La plupart du temps nous n'arrivons pas à reproduire les GPF sur nos postes de développement ou mes machines virtuelles de test.
Les postes clients sont des postes bureautiques basiques et ne disposent donc pas d'outils de développement.
Je suis preneur d'astuces ;)
merci
Hors ligne
Bonjour,
Est-tu sur de récupérer une référence valide sur un control ?
J'ajouterai quand même ça pour assurer le coup :
graphicobject u_obj if isvalid(w_general.getactivesheet()) then u_obj=getfocus() IF IsValid(u_obj) THEN u_obj.triggerevent(losefocus!) w_general.getactivesheet().triggerevent("ue_ok") end if
Hors ligne
_francois_ a écrit:
J'ai la stack trace qui s'affiche dans la messageBox unexpected GPF et c'est systématiquement sur la ligne -1 d'un script.
Est-tu partis de mon fork github ?
Je demande çà parce que j'ai patché cette fonction justement pour afficher la dernière ligne de la pile) ?
Hors ligne
xlat a écrit:
_francois_ a écrit:
J'ai la stack trace qui s'affiche dans la messageBox unexpected GPF et c'est systématiquement sur la ligne -1 d'un script.
Est-tu partis de mon fork github ?
Je demande çà parce que j'ai patché cette fonction justement pour afficher la dernière ligne de la pile) ?
je ne sais plus d'où j'ai pris le source des fastfuncs
j'ai un répertoire fastfuncs-master datant d'avril 2013
à priori je l'ai récupéré de là https://github.com/lakeman/fastfuncs
je vais tester ton fork pour voir.
Hors ligne