Discussion :

[daerlnaxe]

bonjour, j'ai décidé de me faire un équivalent maison du filesystemwatcher mais d'une manière plus basique, celui ci ne correspondant pas à mes attentes.

Donc en gros j'initialise une premiere liste, avec les ids des fichiers, puis je vais faire une boucle régulière qui dresse la liste des fichiers avec Directory.EnumerateFiles et qui traite uniquement ce qui change avec diverses boucles.
J'ai pas de bug, la première initialisation me prendre 500ms max et les autres c'est variable en cas de changement ou pas, mais pour un fichier c'est 3à 5ms.

A un moment donné le débugger me signale une erreur que je ne comprends pas vraiment, sous visual studio ça fait une page blanche, ça ne me dit pas qu'il y a une erreur dans le code, et je peux poursuivre ensuite.
Ma boucle principale est planifiée sur 1ms de délais à chaque tour pour dresser cette liste.

"Votre application est à l'état d'arrêt, mais aucun code pris en charge par le moteur de débogage sélectionné n'est en cours d'exécution (par exemple, seul du code de runtime natif est en cours d'exécution)."
sur cette page blanche

Et dans la partie sortie ça me marque:
"Assistant Débogage managé 'ContextSwitchDeadlock'
Le CLR n'a pas pu effectuer de transition du contexte COM 0x138a618 au contexte COM 0x138a560 pendant 60 secondes. Le thread qui possède le contexte/cloisonnement de destination est probablement en train d'attendre ou de traiter une opération très longue sans pompage des messages Windows. Cette situation a généralement des effets négatifs sur les performances et peut parfois entraîner le blocage de l'application ou une utilisation ininterrompue de la mémoire. Pour éviter ce problème, tous les threads STA (Single Threaded Apartment) doivent utiliser des primitives d'attente de pompage (par exemple CoWaitForMultipleHandles) et pomper de manière régulière les messages lors des opérations qui sont longues à s'exécuter.

"

Précision pour tester cette partie je ne me suis pas cassé la tête je l'iniatialise au loaded de l'applicatoin vu que j'étais principalement concentré sur la création de cette classe je ne voulais pas trop modifier mon code. Est ce que ça pourrait être en rapport ?

Merci pour votre aide, là j'ai du mal à comprendrE.

[Pol63]

par défaut le code que tu tapes s'exécute sur le thread principal de l'application
ce thread sert aussi au rafraichissement de l'interface (et le vidage de la pompe à message du coup)
aussi quand on fait quelque chose de potentiellement long (genre plus de 200ms) ou à durée incertaine potentiellement longue (connexion à quelque chose de distant ...) on le fait sur un autre thread, ce qui évite que l'appli ne bloque

si tu ne veux pas t'embeter avec les threads il y a le backgroundworker, ou encore les tasks
par contre depuis un autre thread que le principal il est impossible de modifier l'interface, sinon ca plante, avec un thread on utilise alors des invokes, le backgroundworker a un event relayé sur le thread principal, et les tasks gèrent ca tout seul

si tu veux faire un genre de timer sur un thread tu peux faire un while (true) { traitement + thread.Sleep(x millisecondes) }

[daerlnaxe]

Merci pour ces informations, en fait jusqu'à présent j'avais correctement programmé donc ça ne m'était pas encore arrivé. Là j'ai voulu bâcler pour faire vite juste en appelant la fonction, donc je vais intégrer ça dans le reste proprement.

je travaille avec des tasks pour les longs calculs donc ce type d'erreur ne m'étais jamais arrivé avant.

Merci pour tout y compris pour le surplus d'information au cas ou.

[Noxen]

si tu veux faire un genre de timer sur un thread tu peux faire un while (true) { traitement + thread.Sleep(x millisecondes) }

Il me semble que dans les différentes classes de timer du framework il y en a une plus spécifiquement dédiée au Threads.