Wenn du Daten zwischen den ViewModels austauschen willst, dann müssen diese sich kennen (d.h. gib entsprechende Referenzen weiter).
Alternative wäre ein übergeordnetes ViewModel, das dann die Daten an die Sub-ViewModels weiterreicht.
@Abt: Ja, du hast recht, die ganze foreach-Schleife ist hier überflüssig - ich habe gestern übersehen, daß hier keine Überprüfung der einzelnen OpenTask vorgenommen wird, sondern nur ob die UserId schon existiert oder nicht.
PS: Bzgl. var - dann solltet ihr nicht meine Codes sehen...
Aber auch hier die erste Zeile sollte m.e. besser
var result = new Dictionary<long, List<TaskTO>>();
oder aber
Dictionary<long, List<TaskTO>> result = new();
geschrieben werden.
Wobei ich mich hier generell frage, warum hat TaskTO nicht eine Methode zum Abfragen der OpenTasks?
Man könnte auch ein "Shared"-Verzeichnis als Austausch nehmen: Accessing Local Files and Folders on Remote Desktop Session oder File Sharing through RDP from Windows
Das Remote-Programm würde also z.B. eine Textdatei erzeugen (mit der Liste der Programme) und ein Client-Programm diese einlesen und versuchen die Programme zu öffnen.
So könnten dann auch noch die Dokumente übergeben werden (ich nehme mal an, daß nicht einfach nur Word, Excel o.ä. mit einem leeren Dokument gestartet werden soll).
Nur zur Info. ILMerge gibt es weiterhin auf GitHub: ILMerge (und auch als NuGet Package), aber du hast recht, es funktioniert nicht mit WPF, da es die XAML Ressourcen nicht korrekt einbinden kann.
Aber es gibt LibZ als Alternative. ;-)
Ich gebe dir einfach mal ein paar Stichworte für die Teilaufgaben:
- TextBox: im KeyPress- oder KeyDown-Ereignis auf Enter/Return-Taste (Key.Enter bzw. '\r') abfragen
- Chart: Series anlegen und Werte dort initial (d.h. mit 0) eintragen, danach die Werte an entsprechender Position (1-5) erhöhen (bessere Lösung mittels DataBinding: DataSource). Vllt. hilft dir auch folgender Code dazu: Chart Control in Windows Forms Application ?
Edit: Das Löschen der TextBox nach der Eingabe findest du sicherlich alleine raus...
Wenn die nativen Treiber-DLLs per [DllImport] eingebunden sind (und anscheinend nicht dynamisch geladen werden), dann läßt sich das nicht (direkt) abfangen.
Kannst du denn auf die gesamten Unity-Plugin Methoden dann verzichten? Dann könntest du diese (anstatt fest als Verweis anzugeben), mittels Assembly.Load bzw. Assembly.LoadFile laden. Du mußt dann aber dynamisch auf die Methoden zugreifen, s. z.B. Loading DLLs at runtime in C#.
Schau dir mal die Methode GetDateFromWeekNumberAndDayOfWeek aus Get date from weeknumber an (das aktuelle Jahr solltest du dann noch als Parameter übergeben ;-).
In der Methode User_Change wird dann das Window mit der Login-Form wieder aufgerufen.
Ich habe da einen Verdacht - wie rufst du dort das MainWindow wieder auf?
Und ersetze im MainForm-Konstruktor mal this.ShowDialog() durch this.Show() (d.h. dies entspricht this.Visibility = Visibility.Visible). Du möchtest ja nicht das MainWindow innerhalb vom Konstruktor modal anzeigen.
Dann setze das MainWindow doch wieder auf Visible nach dem ShowDialog-Aufruf (d.h. wenn der Login erfolgreich war - ansonsten zeige wieder das Login-Fenster an, solange bis der Anwender "Abbrechen" (Cancel) auswählt).
das ist das Standardverhalten beim Hauptfenster - wenn dieses geschlossen oder nicht mehr sichtbar ist, dann wird die gesamte Anwendung geschlossen (d.h. der Prozess beendet).
Das ist bei WPF nicht so einfach zu umgehen, da der Code dazu automatisch aus den XAML-Daten erzeugt wird (außer mittels des Application.Startup-Ereignisses, aber dann mußt du den gesamten Startup-Code dort erzeugen - s. Beispiel mittels new MainWindow()).
Warum willst du das denn (und was soll der Anwender dann mit deiner Anwendung noch weiter tun können)?
Diese Eigenschaft ist für diese Klasse nicht relevant.
Der SplitContainer verfügt stattdessen über die beiden Eigenschaften Panel1 und Panel2.
Dein Code verletzt aber grundlegende Prinzipien der OOP, nämlich von einer Klasse (Form) auf die Interna einer anderen Klasse (Form) zuzugreifen, s.a. [FAQ] Kommunikation von 2 Forms (bzw. mein eigener Artikel zum Thema: Kommunikation von 2 Forms).
Ein großer Fehler ist jetzt bei dir die erzeugten Endlosschleifen (schau mal im TaskManager auf die Prozessor-/Kernauslastung)!
Du mußt diese wartend oder blockierend machen (oder ist GetByteFromDevice() blockierend, da du ja von ConcurrentQueue und BlockingCollection geschrieben hast?). Zumindestens für die Sendeschleife sollte ein Thread.Sleep(x) hin (bei Benutzerauslösung der Flags reichen einige 100ms).
PS: Sofern du konstante Daten versendest, kann du einfach z.B. byte[] txData = { 4, 1, 2, 3, 4 }; schreiben (und sogar den string str einmalig vor der Schleife erzeugen - bzw. 2 für die beiden Fälle).
Sorry wegen den Syntax-Fehlern, aber ich konnte deinen Code ja nicht bei mir testen (sondern habe ihn nur im Editor abgeändert).
Und wegen der Exception: Du mußt ja auch die OperationCanceledException abfangen.
Ich meinte aber nicht explizit bei jedem Kopieren-Aufruf, sondern um alle Aufrufe (also von #region Dateien kopieren bis #endregion Dateien kopieren
/#endregion Sicherungsprotokoll erstellen - je nachdem ob und was du im Fall einer Exception in das Sicherungsprotokoll schreiben möchtest).
Wenn diese Exception trotzdem nicht gefangen wird, dann probiere mal, das token auch an die Task.Run-Methode zu übergeben.
meinte ich zum einen die unnötige zweifache Zuweisung von Visibility als auch daß du auf die Page.Visibility zugreifst (meintest du nicht eher Visibility.Visible?).
Das Auslagern der Kopier-Klasse in eine eigene Datei ist auf jeden Fall zu empfehlen (und wie schon geschrieben, verwende static, dann reduziert sich auch dein Code beim jeweiligen Aufruf zu Kopier.Kopieren(Quelle, Ziel, token) - bei Kopieren(Quelle, Ziel) müßtest du noch eine Hilfsmethode in deiner Sichern-Klasse erzeugen).
PS: XCopy ruft intern auch nur die entsprechenden System-Funktionen zum Kopieren von Verzeichnissen und Dateien auf (je nach Parameter), aber leider gibt es direkt für die XCopy-Funktionailtät keine API.
Es gäbe auch noch FileSystem.CopyDirectory, aber das unterstützt auch kein Abbrechen des Vorgangs.
OK, geänderter Code im Anhang.
Meine Änderungen habe ich mit // by Th69 kommentiert.
Du mußt jetzt noch um deine ganzen Kopiermethoden in der Go-Methode noch ein try ... catch (OperationCanceledException) setzen, damit diese Exception gefangen wird und alle weiteren Kopiermethoden nicht mehr aufgerufen werden (ich habe dies extra nicht gemacht, um deinen Code nicht weiter zu ändern, wie du ja auch geschrieben hast ;-).
Bedenke außerdem, daß beim Kopieren einer großen Datei auch erst nach Abschluß der Kopiervorgang unterbrochen wird (ansonsten müßtest du selber das Dateikopieren implementieren und dort dann für jeden Dateiblock token.ThrowIfCancellationRequested() aufrufen).
Aber noch ein paar sonstige Anmerkungen zu deinem Code:
- Niemals Pfad-Literale (wie z.B. "C:\Users\" oder @"\Desktop") im Code benutzen, sondern immer Environment.GetFolderPath benutzen (die Pfade können je nach System immer unterschiedlich sein)!
- Du erstellst immer wieder (unnötigerweise) neue Kopier-Objekte - da die Kopieren-Methode keine Instanzmember benutzt, sollte sie static sein (sollte auch von der CodeAnalyse als Warnung angezeigt werden).
- Du benutzt zwar schon teilweise die Path-Methoden, aber nicht konsequent. Alle Funktionalität bzgl. @"\" solltest du mit Path-Methoden programmieren.
(Wegen der using-Anweisung brauchst du nicht immer System.IO. vor Benutzung zu schreiben)
- Du hast mehrfach Desktophaken.Visibility = Visibility = Visibility; im Code stehen??? Und auch Desktopbox.Visibility sowie Desktopkreis.Visibility setzt du unnötigerweise jedesmal wieder beim Kopieren eines Verzeichnisses.
Viel Erfolg noch!
PS: Die Sichern.xaml scheint dieselbe Datei wie Sichern.xaml.cs zu sein!?!
Es ist so ähnlich, wie du die Variable Abbruch gedacht hast, nur daß es thread- bzw. tasksafe ist. Du mußt nur in deinen Kopierschleifen den CancellationToken.IsCancellationRequested-Status überprüfen und dann ThrowIfCancellationRequested() aufrufen.
Lege dazu CancellationTokenSource als Membervariable an und rufe über das "Abbrechen"-Command dann dafür Cancel() auf (diese Variable mußt du dann noch als Parameter zusätzlich der Kopieren-Methode übergeben, damit diese darauf zugreifen kann).
PS: Dateipfade solltest du mit der Path.Combine-Methode zusammensetzen.