Comparaison de Timer avec DispatcherTimer

qu'est-ce qu'une différence between System.Windows.Forms.Timer()et System.Windows.Threading.DispatcherTimer()? Dans quels cas, faut-il les utiliser? des meilleures pratiques?

c# timer

— paradisonoir
source

111

Windows.Forms.Timerutilise la boucle de message de Windows Forms pour traiter les événements du minuteur. Il doit être utilisé lors de l'écriture d'événements de minutage qui sont utilisés dans les applications Windows Forms et que vous souhaitez que le minuteur se déclenche sur le thread d'interface utilisateur principal.

DispatcherTimerest le mécanisme de synchronisation WPF. Il doit être utilisé lorsque vous souhaitez gérer le minutage de la même manière (bien que cela ne soit pas limité à un seul thread - chaque thread a son propre répartiteur) et que vous utilisez WPF. Il déclenche l'événement sur le même thread que le Dispatcher.

En général, WPF == DispatcherTimer et Windows Forms == Forms.Timer.

Cela étant dit, il y a aussi System.Threading.Timer, qui est une minuterie classqui se déclenche sur un thread séparé. C'est bon pour le timing purement numérique, où vous n'essayez pas de mettre à jour l'interface utilisateur, etc.

— Reed Copsey
source

Merci pour votre réponse rapide. Cela signifie donc que chaque fois que je veux avoir une minuterie liée à l'interface utilisateur, je devrais utiliser DispatcherTimer, et lorsque je veux déclencher une minuterie, que je ne veux pas geler UL, je devrais utiliser System.Threading.Timer dans un autre fil. La deuxième question est la suivante: si je veux utiliser DispatcherTimer et que je veux avoir une minuterie non liée à l'interface utilisateur, dois-je l'appeler dans un thread séparé en utilisant System.Threading.Timer ou encore DisptacherTimer?

— paradisonoir

Cela dépend de ce que vous essayez de faire. J'utilise rarement System.Threading.Timer - Je m'en tiens généralement à Dispatcher Timer, puis je fais votre TRAVAIL (ce qui pourrait bloquer votre interface utilisateur) dans un autre thread, en utilisant quelque chose comme un BackgroundWorker. Les minuteries ne devraient jamais bloquer votre interface utilisateur, sauf si vous faites «trop» de travail dans leur gestionnaire d'événements.

— Reed Copsey

J'ai un problème avec DispatcherTimer qui consomme le processeur au fil du temps. Y a-t-il un bon moyen de gérer cela?

— discorax

Vérifiez ce qui mange spécifiquement le processeur. Créez-vous beaucoup de minuteries qui ne sont pas arrêtées?

— Reed Copsey

Assurez-vous de définir correctement la propriété d'intervalle. Ne faites pas cela: timer1.Interval = new TimeSpan (1000); // "1000" représente des ticks et non des millisecondes! Le processeur était super élevé, jusqu'à ce que je le corrige avec ceci: timer1.Interval = System.TimeSpan.FromSeconds (1);

— Lonnie Best

J'ai trouvé un bon article sur les minuteries avec de petits exemples ici: http://www.progware.org/Blog/post/Timers-in-WPF.aspx

Comme conclusion:

Si DoSomething () manipule les composants de l'interface graphique, vous devez utiliser: this.Dispatcher.Invoke (délégué (Action) {// GUI ASSOCIÉ CODE ICI} car vous ne pouvez pas accéder directement aux contrôles GUI à partir d'un thread différent. Avec DispatcherTimer, vous le faites pas besoin de faire cela.

Si DoSomething () effectue une tâche chronophage, alors l'interface graphique se fige dans le cas de DispatcherTimer. Dans le cas du Timer, ce ne sera pas le cas puisque le long méthos est exécuté dans un thread différent

— Chercheur
source