[WPF] Sequientielles Ausführen von Funktionen

[joggel]

Guten Morgen liebe Gemeinde,

ich habe ein kleines Designproblem. Besser gesagt: ich kann es nur unschön lösen.

Folgendes:
Ich klicke auf einen Button, es öffnet sich ein Datei-auswahl-Dialog; ich wähle mir eine Datei aus und drücke okay.
Also sprich: Ich übergebe dem Eventhandler des Buttons beim Klicken eine Funktion (onButtonClick) , die mir ein OpenfileDialog anzeigt.
Innerhalb dieser Funktion lese ich auch noch die Datei aus.

Jetzt möchte ich noch weiteres mit den ausgelesenen Daten machen. Grafisch darstellen zum Beispiel, what ever...

Nun finde ich das irgendwie extrem unschön, vom Design her, dieses Darstellen, oder was auch immer, noch zusätzlich in die onButtonClick-Funktion zu implementieren.
Am liebsten würde ich die onButtonClick-Funktion ausführen lassen, und im Anschluß dann eine ProceedData-Funktion oder so...

Gibt es da einen Weg in WPF/C#?

[xq]

Klar, im Zweifel machst du einfach einen Function Call :P

Aber das wäre sehr unsauberer Stil, du möchtest sowas in einem Hintergrund-Thread machen. Dafür gibt es in C# entweder System.Threading oder System.Threading.Tasks, wobei letzteres die bevorzugte Variante ist, da du damit wesentlich besser Fehlerbehandlungen und sowas machen kannst.

Das ganze nennt sich dann TPL, Task Parallel Library, mit welcher du auch solche Sachen machen kannst:

Code: Alles auswählen

await Task.Run( () => DoSomeAsyncWork() );
DoSomeWorkAfter();

Ich bin da aber auch noch nicht ganz durchgestiegen, wie das richtig tut, hab es ehrlich gesagt, noch nie wirklich verwendet

[joggel]

Jo, danke erstmal.

Ich meine das aber anders:
Ich möchte eigentlich komplett die GUI-Aktivitäten und meine Programmlogik trennen.
Also die Funktion die durch das Klicken des Buttons aufgerufen wird, soll etwas machen (Datei auswählen und auslesen) und nur das. Dann Funktion eben beenden.
Danach soll dann automatisch eine andere Funktion aufgerufen werden.....

Aber wenn ich so darüber nachdenke... Dann müßte es ja so etwas wie eine Hauptsteuerung (Haupt-Thread?) geben, die das GUI verwaltet/darstellt/etc und dann nur einzelne Funktionen bei bestimmten Ereignissen (in seperaten Threads) aufruft! Naja...und da müsste es ja vlt eine Möglichkeit geben seine Function Calls irgendwo mit dranzuhängen.

Aber ich habe gerade etwas gefunden:

Code: Alles auswählen

<Button x:Name="buttonSoUndSo" Content="soUNdSo" Click="OpenProtokoll" Command="NavigationCommands.GoToPage" CommandParameter="Pages/PageXYZ.xaml"/>

Nur frage ich mich, was der Unterschied zwischen diesen Commands und den Ereignissen (Click) ist? Ich weiß auch nicht was es alles für Commands da gibt....
Ich werd mal google befragen^^

[joggel]

Ich weiß nicht. Die Commands rufen ja auch nur irgendwelche Funktionen oder so auf...

Irgendwie gefällt mir das alles nicht.

Ich bräuchte so einen Main-Thread der meine DatenContainer immer überprüft und bei Änderungen sofort reagiert.
Also, in meinem Beispiel:
- Daten werden gelesen
- Main-Thread sieht das Daten da sind => er erstellt neues Fenster und zeichnet darin Diagramme auf grundlage der Daten.

Sowas wäre irgendwie cool.
Vlt bin ich auch nur gerade total übermotiviert bei meinem Desing :P
(Oder vlt hat mich dieses WPF ganz unterschwellig so beeinflußt, das ich jetzt ganz automatisch MVVM verwenden will!!^^)

[NytroX]

Dann mach das doch so :P
Du kannst ja einfach das Ergebnis in ein Objekt vom HauptThread packen. Und der kann dann darauf reagieren.

In .NET könntest du z.B. einen Task dazu verwenden, indem du der GUI eine TaskFactory mitgiebst. Der Task wird von der GUI erzeugt und hat ein Bild als ResultType.
Dann kann bei einem Klick in der GUI der Task ausgeführt und dem HauptThread übergeben werden, und die GUI kehrt sofort zurück.

Das Laden des Bildes passiert dann asynchron, und der HauptThread hält den Task.
Wenn der dann fertig ist (task.isCompleted()), weißt du dass das Bild geladen ist und kannst damit arbeiten.

https://msdn.microsoft.com/en-US/librar ... .110).aspx


Das Problem an (GUI-) Frameworks ist meistens, dass sie versuchen, alles zu übernehmen und selbst der Hauptbestandteil deiner Software zu sein.
Dein Gefühl ist schon genau richtig; die GUI sollte weggekapselt werden und nur GUI/Frontend Sachen machen, und das Ergebnis deinem eigentlichen Programm mitteilen.

[joggel]

Das klingt sehr cool. Und wahrscheinlich auch nicht allzu schwierig.

Da ich gerade mit meiner Software neu anfange, also ich will sie mit WPF neu schreiben, anstatt mit WinForms.
(Es ist nur ne kleine Software die Dateien ausliest, Diagramme daraus erstellt, paar Tabellen darstellt, das als PDF rendert oder ausdruckt....und noch paar Spielerein macht.)

Ich glaube, ich werde das so machen mit dem MainThread und der Task<> Geschichte...

Das Problem an (GUI-) Frameworks ist meistens, dass sie versuchen, alles zu übernehmen und selbst der Hauptbestandteil deiner Software zu sein.
Dein Gefühl ist schon genau richtig; die GUI sollte weggekapselt werden und nur GUI/Frontend Sachen machen, und das Ergebnis deinem eigentlichen Programm mitteilen.

Ich glaube das ist auch der Gedanke hinter diesem MVVM-Pattern was ja WPF nutzt.
Das GUI reagiert auch direkt auf Änderungen, weil man dem GUI eben nur eine Schnittstelle zu den Daten übergibt...und diese Schnittstelle informiert die GUI falls sich etwas an den Daten geändert hat.
So weit habe ich das im Moment verstanden.

Nur ist es irgendwie etwas mühsam und nervig immer so eine Schnittstelle zu den Daten zu bauen. Die müssen dann von einer Klasse erben und irgend welche Events dann triggern.
Ach...so genau habe ich das eben nicht verstanden :?

Aber diese ThreadGeschichte scheint mir verständlicher....und cooler 8-) ^^

[joggel]

Ich komme nicht so richtig weiter...

Wie würde ich denn so eine TaskFactory realisieren und wie würde ich sie verwenden?
Hat da jemand einen Tipp?

Mal evtl. am Beispiel von einer Dateiauslesen, also auswählen der Datei durch einen OpenFileDialog.
Die funktion ReadFile sollte dann in einem neuen Thread starten, und das Ergebnis an meinen internen HauptThread zurück geliefiert werden.
Das Ergebnis wäre eine Klasse vom typ Protocol.

HauptThread:
Ich habe eine Klasseninstanz statisch in der App-Klasse instanziiert (InternMainClass)
Diese InternMainClass soll alles an Programmlogik übernehmen was es so gibt...

Was haltet ihr davon?


/////////
Kleiner Nachtrag!!
Ganz anders:
Bei dem Klick auf den Button "Öffnen" wird eine Funktion InternMainClass.readFile(openFileDialog.FilenName) aufgerufen.
In dieser Funktion wird ein Thread gestartet, in dem ein Reader die Datei ausliest, und ein Protocol zurückgibt.
Damit kann dann die InternMainClass machen was sie auch sonst immer will....
Das halte ich für eine saubere Lösung!!!

[hagbard]

Unabhängig von der Programmiersprache:
Sei vorsichtig damit für jede kleine Aktion einen Thread zu starten und wieder zu beenden. Zuviele Kontextwechsel pro Sekunde können sehr auf die CPU Last gehen.
Es ist besser einen Arbeitsthread (oder wenn es rechenintensive Sachen sind auch einen Threadpool) zu haben denen man einfach Aufgaben übergibt und der genausolange lebt wie die GUI.