PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Gros problème avec l'autodiagnostic des threads depuis migration en WD24
Gros problème avec l'autodiagnostic des threads depuis migration en WD24
Débuté par Jérôme, 27 déc. 2018 18:23 - 11 réponses
Membre enregistré
7 messages
Popularité : +1 (1 vote)
Posté le 27 décembre 2018 - 18:23
Bonjour,

Depuis que mon projet a été migré en WD24, j'ai de gros soucis avec les threads.
J'ai notamment une fonction qui gère une liste image via un thread. Dès qu'elle effectue une opération sur cette liste (listeAjoute, listeModifie, listeInsère,...), une erreur fatale est déclanchée

J'ai essayé de contourné le problème en ajoutant une section critique autour des fonctions à problème (bien que ce soit en théorie inutile, puisqu'il n'y a qu'une fonction bouclant dans un thread infini qui y accède)

A ce stade, le problème est critique pour moi; toute aide sera donc la bienvenue.

Exemple de message:
/* le code de la ligne 109 est: lImage.Insère(libImage,"",lImage+1) */

Erreur à la ligne 109 du traitement Procédure locale repertoireSurveilleAction.
L'autodiagnostic des threads a détecté un comportement interne inattendu.

**********************************************

----- Informations techniques -----

Appel WL :
Traitement de 'Procédure locale repertoireSurveilleAction' (fNumerise.PROCEDURE.repertoireSurveilleAction), ligne 109, thread 0

Que s'est-il passé ?
L'autodiagnostic des threads a détecté un comportement interne inattendu.

Code erreur : 2947
Niveau : erreur fatale

Dump de l'erreur du module 'wd240vm.dll' (24.0.205.2).
Identifiant des informations détaillées (.err) : 2947
Informations de débogage :
UEL = 211
Erreur hors execution
Informations supplémentaires :
EIT_PILEWL :
Procédure locale repertoireSurveilleAction (fNumerise.PROCEDURE.repertoireSurveilleAction), ligne 109
Procédure locale threadRepertoireSurveille (fNumerise.PROCEDURE.threadRepertoireSurveille), ligne 19
EIT_DATEHEURE : 27/12/2018 17:58:37
EIT_TYPE_WDFILE : <2>
EIT_IDCODE : <458752>
Membre enregistré
281 messages
Popularité : +24 (26 votes)
Posté le 28 décembre 2018 - 08:56
Bonjour,

Il est interdit de manipuler des éléments de l’IHM depuis un thread secondaire. PCSOFT à peut-être durci cela en v24.
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 28 décembre 2018 - 09:08
Bonjour,

Comme le dit Damien, il est interdit de manipuler l'IHM dans les threads. Pour faire cela, il faut que u passes par la fonction ExécuteThreadPrincipal() pour manipuler les objets de l'IHM.

Extrait de l'aide
Attention : il est interdit de manipuler l'interface (fenêtres, champs, ...) dans un thread secondaire.
Lorsqu'un thread secondaire doit interagir avec l'utilisateur ou mettre à jour l'interface, il doit utiliser un traitement lancé depuis le thread principal. Ce traitement peut correspondre à :
•une procédure globale du projet ou une procédure locale (d'une fenêtre, ...) appelée par la fonction ExécuteThreadPrincipal,
•le traitement "Demande de mise à jour de l'affichage" d'une fenêtre exécuté grâce à la fonction DemandeMiseAJourIHM.


--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
7 messages
Popularité : +1 (1 vote)
Posté le 28 décembre 2018 - 10:31
Bonjour

Merci beaucoup pour cette réponse qui répond tout-à-fait à mon problème.
WD24 est plus rigoureux, car mon code fonctionnait avant, violant effectivement le principe de non-modification d'éléments d'interface par un thread secondaire.
Et cela m'a permis de découvrir la fonction ExécuteThreadPrincipal que je ne connaissais pas.

Encore merci
Jérôme
Membre enregistré
1 623 messages
Popularité : +100 (114 votes)
Posté le 28 décembre 2018 - 15:49
Petite question au passage @Philippe et @Damien :

ExécuteThreadPrincipal() met'il fin au thread secondaire qui l'execute ? (Un peu comme Renvoyer ou Retour)

Si non :
Lorsque le thread secondaire execute " ExécuteThreadPrincipal()"
Il "attend" la fin du traitement pour continuer ou pas ?

Merci :)
Message modifié, 28 décembre 2018 - 15:50
Membre enregistré
281 messages
Popularité : +24 (26 votes)
Posté le 28 décembre 2018 - 18:59
Il execute le code dans le thread principal quand celui-ci est libre. Cette fonction est bloquante.

Je crois que la fonction DemandeMajIHM ne l’ai pas...
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 28 décembre 2018 - 20:32
@François C.: Il ne met pas fin au thread secondaire, mais comme le dit Damien, l'appel à ExecuteThreadPrincipal est bloquant. Par contre DemandeMiseAJourIHM() se fait de manière asynchrone, il ne doit donc pas être bloquant.

--
Cordialement,

Philippe SAINT-BERTIN
Posté le 20 février 2019 - 09:17
Bonjour,
j'ai le même problème avec WD24 quand j'exécute un thread qui utilise une fonction pour imprimer un état cela me revois cette erreur "L'autodiagnostic des threads a détecté un comportement interne inattendu ",
est ce que vous auriez une solution sachant que dans WD23 j'en avais aucun problème????
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 20 février 2019 - 09:32
Bonjour,

Oui suivre les remarques précédentes.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
7 messages
Popularité : +1 (1 vote)
Posté le 20 février 2019 - 10:58
Je confirme; appeler les fonctions agissant sur l'interface avec ExécuteThreadPrincipal résoud le problème.
Membre enregistré
48 messages
Popularité : +0 (2 votes)
Posté le 19 août 2019 - 11:17
Bonjour,

J'ai le même problème. Sur chacune des pages de mon sites, faire une recherche, lance un thread ET un timer, le Thread exécute la requête et fait les ZRAjouteLigne directement (cela marchait en 23 même si je sais que c'est déconseillé), le timer lui modifie une jauge en fonction de l'avancement du thread et fait un ZRAffiche quand le thread est terminé.

J'ai essayé de placer mes ZRAjouteLigne dans une procédure interne que j'appelle avec ExecuteThreadPrincipal, mais ça bloque mon Thread, j'ai essayé DemandeMAJIHM, pas de meilleur résultat ...

J'ai ensuite trouvé un moyen de faire exécuter mes ZRAjouteLigne par le thread principal : le thread stocke les données dans un tableau (variable globale à la page), et mon timer fait les ZRAjouteLigne à partir du tableau dans lequel le thread a stocké les données.

Ça fonctionne effectivement, mais j'ai divisé par 2 les performances de mon site, mes recherches prennent deux fois plus de temps et c'est fort dommage.

LE PIRE c'est que mon code marche, actuellement sur ma version de test en v24 (avec mes threads avec des modifications de champs de la page), il n'y a que ma première recherche qui ne marche pas ....

Si je fais une recherche sur une page A, ça ne marche pas car "l'autodiagnostic des threads a détecté un comportement inattendu" (en debugant je vois que c'est effectivement mes ZRAjouteLigne qui posent problème), ensuite il me suffit de passer sur une page B, de lancer une recherche (qui marche), de revenir sur la page A, de lancer EXACTEMENT la même recherche qu'avant, et ça fonctionne ....

Pourquoi ?
Merci pour vos lumières qui m’empêcheront de sombrer dans la démence
Posté le 18 mai 2020 - 11:36
Bonjour le problème subsiste toujours dans le driver HyperFile OLEDB, aussi bien en mode 32 bits qu'en mode 64 bits.
J'arrive à le reproduire dans un programme Visual Basic qui n'est pas multi-thread.
Sub Main
Connexion à la base de données HyperFile d'un serveur
Première Requête avec un DataReader
Deuxième requête avec un DataReader
Déconnexion de la base
End Sub
L'erreur au moment où le programme s'arrête (End Sub)
Il faut passer deux ou plusieurs requêtes pour provoquer l'erreur.