Laden...

SubForm in neuen Thread auslagern

Erstellt von Rico913 vor 3 Jahren Letzter Beitrag vor 3 Jahren 289 Views
R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren
SubForm in neuen Thread auslagern

Hi,

ich habe ein Programm (Main_Form) und ein entsprechendes SubForm. In diesem Form lade ich eine dynamische Excel-Tabelle in ein DataGrid, welches ich nach bestimmten Anforderungen im Main_Form filtere.
Nun ist es so, dass es je größer die Tabelle ist, es spürbar länger dauert, bis ich im Main-Form eine Aktion ausführen kann.

Ist es möglich, das ganze SubForm in eine Art Backgroundworker o.ä. auszulagern? Und wenn ja, wie ist das Stichwort dafür? Können dabei Main_Form und SubForm "kommunizieren"?

Danke und viele Grüße
Rico

16.834 Beiträge seit 2008
vor 3 Jahren

Nein. UI Elemente wie Forms, Controls, Windows.. müssen im Hauptthread laufen.
Das Laden von Daten kann / sollte ausgelagert werden.

[FAQ] Warum blockiert mein GUI?

4.939 Beiträge seit 2008
vor 3 Jahren

Hallo,

alle Interaktionen mit der UI müssen zwingend im Main-Thread (UI-Thread) ausgeführt werden, nur Berechnungen können ausgelagert werden, s.a. [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke).

Und in [FAQ] Warum blockiert mein GUI? stehen noch weitere Möglichkeiten.

J
641 Beiträge seit 2007
vor 3 Jahren

Es geht schon auch multiThreading mit mehreren Prozessen... macht ja z.b. Visual Studio so mit dem XamlDesigner.

Es gab dazu auch mal ein Beispiel auf Codeproject: Baktun Shell: Hosting WPF Child Windows in Another Process

cSharp Projekte : https://github.com/jogibear9988

16.834 Beiträge seit 2008
vor 3 Jahren

jogibear9988, das sind Äpfel und Birnen.
Er spricht von Multi Thread UI, was in WinForms - siehe Blick in die Doku - by Design eine schlechte Idee ist.
Der Grund des Wunsches sind in 99,999% Designfehler der Anwendung; hört sich hier ja auch so an.

Dein Link zeigt ein Multi Prozess Konstrukt, was etwas anderes ist und neben Vorteilen (Isolierung, wie sie zB. Browser aus Sicherheitsgründen brauchen / wollen) auch extreme Nachteile hat.
Für Visual Studio bietet sich dieses Konstrukt auch an; für "normale" Anwendungen, die keine IDE darstellen, externe Plugis brauchen, keine Sicherheits-Prozess Isolierungsfeatures des Betriebssystem - eher selten. Dafür hast Du aber einen ungemein riesen Overhead, dass die Prozesse untereinander kommunizieren können.

Hier haben wir eine Anwendung, die nicht reagiert, weil das Laden im UI Thread stattfindet.
Dafür das gesamte Applikationskonstrukt umzubauen: puh, wer will 😉