Je n'ai pas du bien comprendre le fonctionnement des threads car j'ai
un truc bizarre.
Dans l'application 'principale', j'ai une boucle de lecture sur les
enregistrements d'une table ayant un code état à 0.
A chaque fois qu'un enregistrement est trouvé, une thread est créée.
Dans la procédure de la thread, je veux modifier le code état à 9
pendant la durée du traitement de l'enregistrement. Ainsi, si la
boucle de l'appli principale 'repasse' sur le même enregistrement, ce
dernier n'est pas traité puisque grace à son code état à 9, on sait
qu'ul est déjà en cours de traitement dans une thread.
PROBLEME:
Quand dans la thread s'exécute l'instruction hmodifie, après
modification du code état à 9, le traitement de la thread se bloque.
hmodifie ne rends jamais la main pour donner un code erreur par
exemple.
Pourtant, hblocagenon est systématiquement utilisé par sécurité et, de
toutes façons, les contextes hyperfile sont en principes différents
entre la thread et l'appli principale.
Je ne comprends donc pas ce blocage sans message d'erreur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine
Salut, concernant ton pb de blocage sur un hmodifie dans ton thread, je n'ai pas pu reproduire l'incident. Ce que je peut te dire c'est que si depuis ce thread tu manipule les objets de ta fenetre (champ de saisie, libbellé, jauge...), la cela peut être bloquant. Dans ce cas, tu dois faire le traitement indiqué dans la doc "gérer l'ouverture d'une fenetre dans un thread secondaire" sauf que dans ton cas il ne sagira pas d'ouverture de fenetre mais d'affichage d'infos.
A+, Antoine
Alain wrote:
Je n'ai pas du bien comprendre le fonctionnement des threads car j'ai un truc bizarre.
Dans l'application 'principale', j'ai une boucle de lecture sur les enregistrements d'une table ayant un code état à 0.
A chaque fois qu'un enregistrement est trouvé, une thread est créée. Dans la procédure de la thread, je veux modifier le code état à 9 pendant la durée du traitement de l'enregistrement. Ainsi, si la boucle de l'appli principale 'repasse' sur le même enregistrement, ce dernier n'est pas traité puisque grace à son code état à 9, on sait qu'ul est déjà en cours de traitement dans une thread.
PROBLEME: Quand dans la thread s'exécute l'instruction hmodifie, après modification du code état à 9, le traitement de la thread se bloque. hmodifie ne rends jamais la main pour donner un code erreur par exemple. Pourtant, hblocagenon est systématiquement utilisé par sécurité et, de toutes façons, les contextes hyperfile sont en principes différents entre la thread et l'appli principale. Je ne comprends donc pas ce blocage sans message d'erreur.
Salut, concernant ton pb de blocage sur un hmodifie dans ton thread, je n'ai
pas pu reproduire l'incident.
Ce que je peut te dire c'est que si depuis ce thread tu manipule les objets
de ta fenetre (champ de saisie, libbellé, jauge...), la cela peut être
bloquant.
Dans ce cas, tu dois faire le traitement indiqué dans la doc "gérer
l'ouverture d'une fenetre dans un thread secondaire" sauf que dans ton cas
il ne sagira pas d'ouverture de fenetre mais d'affichage d'infos.
A+, Antoine
Alain wrote:
Je n'ai pas du bien comprendre le fonctionnement des threads car j'ai
un truc bizarre.
Dans l'application 'principale', j'ai une boucle de lecture sur les
enregistrements d'une table ayant un code état à 0.
A chaque fois qu'un enregistrement est trouvé, une thread est créée.
Dans la procédure de la thread, je veux modifier le code état à 9
pendant la durée du traitement de l'enregistrement. Ainsi, si la
boucle de l'appli principale 'repasse' sur le même enregistrement, ce
dernier n'est pas traité puisque grace à son code état à 9, on sait
qu'ul est déjà en cours de traitement dans une thread.
PROBLEME:
Quand dans la thread s'exécute l'instruction hmodifie, après
modification du code état à 9, le traitement de la thread se bloque.
hmodifie ne rends jamais la main pour donner un code erreur par
exemple.
Pourtant, hblocagenon est systématiquement utilisé par sécurité et, de
toutes façons, les contextes hyperfile sont en principes différents
entre la thread et l'appli principale.
Je ne comprends donc pas ce blocage sans message d'erreur.
Salut, concernant ton pb de blocage sur un hmodifie dans ton thread, je n'ai pas pu reproduire l'incident. Ce que je peut te dire c'est que si depuis ce thread tu manipule les objets de ta fenetre (champ de saisie, libbellé, jauge...), la cela peut être bloquant. Dans ce cas, tu dois faire le traitement indiqué dans la doc "gérer l'ouverture d'une fenetre dans un thread secondaire" sauf que dans ton cas il ne sagira pas d'ouverture de fenetre mais d'affichage d'infos.
A+, Antoine
Alain wrote:
Je n'ai pas du bien comprendre le fonctionnement des threads car j'ai un truc bizarre.
Dans l'application 'principale', j'ai une boucle de lecture sur les enregistrements d'une table ayant un code état à 0.
A chaque fois qu'un enregistrement est trouvé, une thread est créée. Dans la procédure de la thread, je veux modifier le code état à 9 pendant la durée du traitement de l'enregistrement. Ainsi, si la boucle de l'appli principale 'repasse' sur le même enregistrement, ce dernier n'est pas traité puisque grace à son code état à 9, on sait qu'ul est déjà en cours de traitement dans une thread.
PROBLEME: Quand dans la thread s'exécute l'instruction hmodifie, après modification du code état à 9, le traitement de la thread se bloque. hmodifie ne rends jamais la main pour donner un code erreur par exemple. Pourtant, hblocagenon est systématiquement utilisé par sécurité et, de toutes façons, les contextes hyperfile sont en principes différents entre la thread et l'appli principale. Je ne comprends donc pas ce blocage sans message d'erreur.
