Répartiteur.CurrentDispatcher vs Demande.Actuel.Répartiteur

Question

Quelles sont les différences entre Dispatcher.CurrentDispatcher (en System.Windows.Threading) et Application.Current.Dispatcher (en System.Windows)?

Mon petit doigt me dit qu' Application.Current.Dispatcher ne changera jamais et est globale pour tous les threads de l'application en cours, tandis que d' Dispatcher.CurrentDispatcher peut créer une nouvelle instance d' Dispatcher selon le fil à partir de laquelle il a été appelé.

Est-ce exact?

Si elle l'est, est le but de l' Dispatcher.CurrentDispatcher principalement pour le multi-thread de l'INTERFACE utilisateur?

Answer 1

Mon petit doigt me dit que l'Application.Actuel.Répartiteur ne changera jamais et est globale pour tous les threads de l'application en cours, tandis que Répartiteur.CurrentDispatcher peut créer une nouvelle instance de Répartiteur selon le fil à partir de laquelle il a été appelé.

Qui est correct.

En outre, il n'y a aucun point d'accès Dispatcher.CurrentDispatcher de non-thread d'INTERFACE utilisateur. Il ne fera rien, sauf si vous vous appelez Dispatcher.Run, et de rentrer dans une boucle infinie message n'est pas ce que vous voulez faire de l'intérieur de threads de travail.

Donc:

• Dans le scénario le plus courant, où votre application n'a qu'un seul thread d'INTERFACE utilisateur, Application.Current.Dispatcher et Dispatcher.CurrentDispatcher de dans le thread de l'INTERFACE utilisateur sera de retour la même instance. Celui que vous utilisez est tout simplement une question de préférence.

• Si votre application dispose de plus d'un thread d'INTERFACE utilisateur puis chaque DispatcherObject sera définitivement associée avec le répartiteur de la thread UI il a été créé lors de la construction. Dans ce cas, Application.Current.Dispatcher va se référer à l'opérateur de le fil de votre application généré avec; vous ne serez pas en mesure de l'utiliser pour poster des messages pour les contrôles de vos autres threads l'INTERFACE utilisateur.

Answer 2

Pour le dire simplement...

Dispatcher.CurrentDispatcher obtient le répartiteur pour le thread courant. Donc, si vous êtes à la recherche pour le thread de l'INTERFACE utilisateur du Répartiteur à partir d'un processus en arrière-plan, ne pas l'utiliser.

Application.Current.Dispatcher toujours de vous donner le thread de l'INTERFACE utilisateur du répartiteur, comme c'est le thread qui tourne la seule instance de l'Application.

Answer 3

Mon petit doigt me dit que l'Application.Actuel.Répartiteur ne changera jamais et est globale pour tous les threads de l'application en cours, tandis que le Répartiteur.CurrentDispatcher peut créer une nouvelle instance de Dispatcher en fonction du fil à partir de laquelle il a été appelé.

C'est exact, l' Application.Current.Dispatcher est une propriété d'instance de l'application qui est affecté lors de la construction afin d'être le répartiteur de le thread courant. Et comme la documentation de l' Dispatcher.CurrentDispatcher points de:

Obtient le Répartiteur pour le thread en cours d'exécution et crée un nouveau Répartiteur si l'on n'est pas déjà associé au thread.

---

Si elle l'est, est le but de Répartiteur.CurrentDispatcher principalement pour le multi-thread de l'INTERFACE utilisateur?

Éventuellement, je n'ai pas rencontré de toute utilisation dans l'obtention de l'expéditeur d'un thread d'arrière-plan que vous avez habituellement pas d'INTERFACE utilisateur-elments leur appartenant pour lesquelles vous pouvez opérations de la répartition.