Kosinator Geschrieben 25. Juni 2009 Geschrieben 25. Juni 2009 Hallo, ich bin recht no0b in WPF, und versuche eine größere Anwendung zu schreiben (.Net 3.5), mit WPF und Windows.Forms. Dabei möchte ich möglichst viel Multithreading nutzen um auf der höhe der Zeit zu leben^^ Dazu habe ich ein wenig Literatur gelesen, wie etwa hier (insbesondere Kapitel3) oder hier (einfacher zu verstehen, finde ich). Dabei sind bei mir einige Fragen aufgekommen: 1. (jedes) Objekt in C# (insbesondere Forms und WPF-Objekte) sind an sich ja Threads (stimmt das überhaupt), also kann ich jene in einem ThreadPool verwalten (monitor vllt.) 2. Wie kann ich z.B. Meine Anwendung Starten, den Benutzer verifizieren, und während dessen mein Hauptform (WPF- objekt z.B.) "im Hintergrund" laden (bzw. überall im Programm, so z.B. das "AdressenDetail-Form" im Hintergrund aufbauen, während man noch auf der Adressenliste ist, und erst wenn eine Adresse ausgewählt wurde (doppelklichEvent etwa) jenes mit Daten bestücken (wegen mir nur den Filterstring aufs Dataview-Objekt setzten) und dann rasch anzeigen (da das UI schon da ist) ? 3. Mir wären allgemeine Hinweise, links und Erfahrungen lieb, da ich a)Azubi bin (nicht sonderlich versiert), b)Mit WPF noch nicht wirklich gearbeitet habe (kleinere Beispiele und ein Buch zu WPF) und c)mich mit Multithreading nicht so gut auskenne. 4. Hier ist ein kleines CodeBeispiel von meinem zweiten Link: class Program { public delegate void MyDelegate(); private static MyDelegate del; static void Main(string[] args) { ClassA obj = new ClassA(); // Delegate, das die asynchron aufzurufende Methode beschreibt del = new MyDelegate(obj.AsyncTest); // das Delegate vom Typ AsyncCallback beschreibt die Methode, die // der Server nach Beendigung der asynchronen Ausführung aufruft AsyncCallback callback = new AsyncCallback(MyCallbackProc); // die Methode AsyncTest in ClassA asynchron aufrufen del.BeginInvoke(callback, null); // zeitaufwendige Ausführung for(int i = 0; i <= 100; i++) { Console.Write(".P."); Thread.Sleep(10); } Console.ReadLine(); } // die zurückgerufene Methode public static void MyCallbackProc(IAsyncResult ar) { Console.Write("Ich habe fertig."); } } class ClassA { // asynchron aufzurufende Methode public void AsyncTest() { // zeitintensive Ausführung for(int i = 0; i <= 30; i++) { Console.Write(".X."); Thread.Sleep(10); } } } ist etwas in der Art ein guter Anfang, oder gibt es bessere/einfachere Möglichkeiten soetwas zu realisieren? 5. Ja, ich weiß, mein Freund google hat mich mit Infos bereits Eingedeckt, aber ich hoffe auf Erfahrungen und Tipps, die ich beim durchforsten hunderter Hitz nicht rauspicken kann. (Türlich habe ich die Hilfe zu der Klasse "Threads" gelesen. Gruß, Kosi Zitieren
TDM Geschrieben 25. Juni 2009 Geschrieben 25. Juni 2009 Dabei möchte ich möglichst viel Multithreading nutzen um auf der höhe der Zeit zu leben^^ Schlechte Idee, Multithreading nur dort, wo es nötig ist, alles andere macht das Programm zu kompliziert. 1. (jedes) Objekt in C# (insbesondere Forms und WPF-Objekte) sind an sich ja Threads (stimmt das überhaupt) Nein. Ein int ist kein Thread. 2. Wie kann ich z.B. Meine Anwendung Starten, den Benutzer verifizieren, und während dessen mein Hauptform (WPF- objekt z.B.) "im Hintergrund" laden (bzw. überall im Programm, so z.B. das "AdressenDetail-Form" im Hintergrund aufbauen, während man noch auf der Adressenliste ist, und erst wenn eine Adresse ausgewählt wurde (doppelklichEvent etwa) jenes mit Daten bestücken (wegen mir nur den Filterstring aufs Dataview-Objekt setzten) und dann rasch anzeigen (da das UI schon da ist) ? Schau dir mal diese Klasse an. 3. Mir wären allgemeine Hinweise, links und Erfahrungen lieb, da ich a)Azubi bin (nicht sonderlich versiert), b)Mit WPF noch nicht wirklich gearbeitet habe (kleinere Beispiele und ein Buch zu WPF) und c)mich mit Multithreading nicht so gut auskenne. Multithreading ist böse, da du mit einem anderen Thread nicht die Oberfläche verändern darfst. Abhilfe schaffen hier Events. (INotifyPropertyChanged funktioniert wunderbar als Datacontext mit Bindung) Interessant in dem Zusammenhang ist auch lock. 4. ist etwas in der Art ein guter Anfang, oder gibt es bessere/einfachere Möglichkeiten soetwas zu realisieren? Siehe 2. Zitieren
Kosinator Geschrieben 25. Juni 2009 Autor Geschrieben 25. Juni 2009 Danke für die Antwort erstmal, "Schlechte Idee, Multithreading nur dort, wo es nötig ist, alles andere macht das Programm zu kompliziert." (habe das Zitat-Tag noch nicht richtig begriffen^^) Nötig...Ist es ja an sich (in meinem Fall) nirgends, aber es wäre wünschenswert, wenn einige Arbeiten im Hintergrund (danke für den Tip "Backgroundworker") ablaufen könnten. Zumal, einen Threadpool (oder nen Backgroundworker) in der Hinterhand zu haben ist an sich, auch in Bezug auf das mögliche spätere Wachsen einer Anwendung, glaube ich, auch nicht verkehrt. Ich werde mir die Links bei Zeiten ordentlich ansehen. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.