.NET Update WPF Control sur son propre thread d'interface utilisateur dédié

Question

J'ai une application en temps réel qui met constamment à jour un journal d'interface utilisateur (contrôle RichTextBox) sous la forme d'un contrôle ListView. Le contrôle est mis à jour avec les données d'application en cours reçues via les événements. Mon application fonctionnait très lentement et j'ai trouvé que c'était dû au fait que le journal ListView était mis à jour, ce qui bloque le thread de l'interface utilisateur. Comme vous pouvez l'imaginer, l'application semble très insensible à l'utilisateur.

Je sais qu'il est possible de lancer une fenêtre WPF sur son propre thread d'interface utilisateur dédié. Je me demandais s'il est possible d'héberger un contrôle WPF sur son propre thread d'interface utilisateur afin que le thread principal de l'interface utilisateur mette à jour le reste de la fenêtre sans être bloqué?

Si ce n'est pas possible, s'il vous plaît recommander des solutions de rechange pour remédier à ce dilemme.

Merci!

Answer 1

RichTextBox est un contrôle coûteux à mettre à jour régulièrement.

Il n'est pas possible d'héberger un contrôle WPF sur son propre thread d'interface utilisateur. ObservableCollection ne fonctionnera pas dans mon cas, car je n'ai pas d'accès direct aux objets que je lie - Objets de tierce partie.

Ma solution, qui nécessite des modifications minimes, consistait à baser le contrôle du journal de l'interface utilisateur sur un ListView. ListView a été optimisé pour les mises à jour groupées et régulières - grâce à la balise VirtualisedStackPanel.

Answer 2

Vous n'avez pas publié de code, mais pourquoi ne pas lier le ListView à un ObservableCollection? Vous mettez à jour la collection et elle déclenche un événement pour indiquer à l'interface utilisateur qu'elle a été modifiée. C'est elle qui met à jour l'interface utilisateur.

Il y a de nombreux tutoriels sur la façon de le faire - un tel peuvent être trouvés sur Switch On The Code