PureBasic

J'aurais dû préciser dans mon premier post que cet exemple n'était là que pour mettre en évidence mon problème.
Je n'utilise pas les n° mais des variables dont le nom est parlant pour les identifiants d'objets et le ElapsedTime n'était là que pour boucler un certain temps dans la procédure.
Procédure qui, dans mon code original, lance un traitement via des threads et dans laquelle j'attends leurs résultats. Le petite fenêtre qui me posait problème est en fait splashscreen d'attente qui verrouille le programme tant que tous les résultats des threads ne sont pas revenus.
Vous avez pris mon bug reproducer un peu trop au pied de la lettre . C'est ma faute.

Pour la gestion des Threads, préfères les Mutex et les Sémaphores (mais je pense que tu connais aussi) plutôt que le blocage de l'application en attente des retours. En effet, il faut laisser à l'utilisateur la possibilité de faire d'autres actions (ex: déplacer la fenêtre) et surtout de quitter si c'est trop long (ou planté) sans devoir passer par le gestionnaire de tâche du système.

Pas de risque de processus système fantôme, car les threads de PB ne sont pas des threads système mais de simples procédures qui s’exécutent en tâche de fond. Donc en fermant ou même avec un KillThread, PB passe le balai avant de quitter pour laisser la ram clean.

Attention cependant

Fred en personne a déconseillé l'emploi de KillThread .....
de toute façons tout les threads ouverts sont fermés par le systeme a un moment ou a un autre ..


voici ce que dit Fred a ce sujet

Fred a écrit :Pour ainsi dire, KillThread() n'est jamais une bonne solution, car la memoire allouée par le thread (sa propre pile) n'est pas désallouée. C'est une commande à utiliser uniquement quand il y a un vrai probleme (le thread est bloqué etc.).
Un thread se termine correctement des qu'il sort de la procedure qui est passée à CreateThread(). Donc l'idée pour terminer convenablement un thread est de lui faire quitter sa procedure mere, soit via un ProcedureReturn, soit en quittant la boucle via une variable global ou un evemenet etc.

Je ne devrais pas répondre mais bon...

je suis pas d'accords, la version que je donne fonctionnera sur les gros codes !
a partir du moment ou chaque boucle se trouves dans sa procedure .. le contexte est sauf puisque local a la procedure....

Oui, mais...
Une boucle d'évènement "locale" veut simplement dire que le programmeur n'a pas une vision élargie de son code, il ne maîtrise pas son code (d'après moi).

j'aimerai bien justement voir ta simple boucle avec pour son exemple
une centaine de gadget sur la fenetre A
et une centaine de gadgets sur la fenetre B ...

voir pourquoi pas ton code avec 10 fenetres differentes...(qui contiennent autant de gadgets.. bien sur )

Un projet pro ou sem pro n'a jamais des 10zaines de fenêtres ni des centaines de gadgets (bonjour le ralentissement), ici aussi le programmeur a mal anaysé le problème (toujours d'après moi).

tu verra que mon approche "Multi boucles" dans des procedures, sera beaucoup plus lisible qu'une simple boucle
qui tentera de tout gerer ...


enfin... je crois

Oui, au début c'est vrai.
Mais 6 mois ou 1 an plus tard, quand il faudra debogger 20.000 lignes de codes avec 10 fenêtres, bonjour... ; Là on regrette de ne pas avoir une seule boucle. Car D'une façon ou d'une autre, toutes les fenêtres échangent des données avec la boucle principale !
Et puis on augmente trop le risque de fuite de mémoire donc de plantage difficile à diagnostiquer.