Bonjour à tous,
Mon programme contient plusieurs "modules" que l'utilisateur peut utiliser indépendamment grâce à un TabControl, contenant une TabPage pour chaque "module".
Par exemple, un module pour faire une copie de fichiers en lot, un autre module pour convertir une liste de fichiers .csv en fichiers .dbf, un autre module qui renomme une liste de fichiers selon un pattern, etc.
Dans mon module de conversion de fichiers .csv à .dbf, je me suis buté à une exception levée par le CLR, qui me dit que mon application principale n'a pas reçu de messages pour une trop longue période, puisqu'elle était trop occupée par la méthode qui fait la conversion (la conversion prend plus d'une minute dans la majorité des cas).
J'ai donc décidé de déléguer le travail de cette méthode à un autre thread. J'ai utilisé la classe BackgroundWorker, qui fonctionne très bien. Je la notifie entre chaque fichier traité de mettre à jour une ProgressBar dans mon application principale.
Le problème est que tout cela se fait de façon asynchrone, et donc, l'utilisateur peut cliquer un autre module et exécuter d'autres opérations. Je ne VEUX PAS ça. J'ai pensé à barrer tous les contrôles le temps que l'opération asynchrone se fasse, mais ça m'a amené à me questionner si je ne devrais pas utiliser un traitement normal, mais en m'assurant que mon application principale reçoit des messages pour éviter qu'une exception du CLR soit levée. (S'assurer de barrer tous les contrôles d'une application plus grosse et plus complexe au niveau interface pourrait être problématique).
J'ai lu sur le thread-pool du CLR et sur une façon simple d'ajouter une méthode en tant que "work item" dans la queue. Cependant, je doute que je puisse notifier mon application principale du progrès de l'opération pour modifier l'état de ma ProgressBar.
J'aurais besoin de suggestions !
Merci d'avance !
Partager