Utiliser le thread d'interface utilisateur d'une application WPF pour effectuer une tâche de traitement longue sur un élément d'interface utilisateur, mais également mettre à jour une barre de progression dans la même fenêtre

Question

Mon programme consiste en un grand contrôle d'interface utilisateur graphique que je dois passer à environ 15 secondes à recharger de temps en temps. Étant donné que le code de mise à jour fonctionne principalement avec le contrôle d'interface utilisateur (peut-être que 90% de celui-ci définit les propriétés du contrôle), il serait logique de laisser le thread d'interface utilisateur le gérer. Je ne souhaite vraiment pas que le contrôle repasse visuellement pendant le chargement dans un thread distinct de l'interface utilisateur.

Je souhaite également la mise à jour d'une barre de progression qui se trouve dans la barre d'état de la même fenêtre d'application. Y a-t-il un moyen d'enfreindre la règle dans ce cas et de ne peindre que la barre de progression, ou devrais-je simplement ouvrir une nouvelle fenêtre d'application pour que la barre de progression puisse rester?

Que feriez-vous dans ce cas particulier?

Answer 1

Si vous pouvez interrompre votre tâche principale (mise à jour du graphique, par exemple) en plusieurs étapes, vous pouvez exécuter chaque étape en tant que message séparé du répartiteur. Cela permettra de traiter d’autres messages, notamment de vous permettre de mettre à jour les informations de progression.

Le modèle de base est le suivant:

1. Appelez votre tâche principale en indiquant zéro pour l'étape.
2. Effectuez l'étape.
3. S'il y a plus d'étapes, mettez en file d'attente un autre message en passant à l'étape + 1.

Vous pouvez ensuite ajouter des mises à jour en cours aux points appropriés de votre code.

PS. Ne pas dire que c'est votre meilleure option - difficile à dire sans connaître tous les détails. Mais c’est une option.

Answer 2

Ce n'est pas vraiment vrai qu'il n'y a qu'une seule interface utilisateur thread dans une application , la plupart des applications Windows ne créent que des objets d'interface utilisateur dans un seul thread. Ce thread devient ainsi le " le " Interface utilisateur dans l'application. Il est facile de comprendre pourquoi: cela simplifie la compréhension du code et nous protège des problèmes de liaison de thread implicites entre les contrôles.

Cela suggère une idée possible, s’il était impossible d’accélérer la vitesse de mise à jour du contrôle (ce que je suggérerais de faire en premier). Créez le contrôle d'interface utilisateur sur un thread distinct. Vous devez vous assurer que le fil convient à l'interface utilisateur, that c'est-à-dire que le modèle de filetage est STA et qu'il pompera les messages et ne mourra pas avant que le contrôle ne soit détruit. Je ne sais pas si vous devez également créer la fenêtre parente dans le fil de l'interface utilisateur, ou simplement le contrôle, mais cela vaut peut-être la peine d'essayer ici.

Answer 3

Recherchez un contrôle d’interface utilisateur graphique plus efficace. À moins que le fil de l'interface utilisateur ne renvoie la boucle de message, aucune autre mise à jour ne se produira (et cela ralentira les mises à jour de votre contrôle graphique).

Answer 4

Je suggérerais d'utiliser une barre de progression dans une nouvelle fenêtre (sans les en-têtes de formulaire). Faites-le peindre la barre de progression en lisant les propriétés partagées d'un contrôle graphique. De cette façon, vous évitez le blocage du fil (chargement lent) .. Et cela vous donne une bonne expérience visuelle (peinture progressive sur les deux commandes).