KeeperOfCoffee

hmmmm.....

Bei "e.Cancel=true" brichst du das schließen des Windows ab. Wollte ich mal nur erwähnen, falls dir das nicht bewusst ist. Streams implementieren i.d.R. die IDisposable Schnittstelle. Du musst hier also aufpassen und immer darauf achten, diesen auch zu mit Dispose() zu löschen. https://docs.microsoft.com/de-de/dotnet/api/system.io.stream.dispose?view=net-5.0#System_IO_Stream_Dispose Damit wir nicht immer .Dispose() schreiben müssen nutzten wir i.d.R. "using" https://docs.microsoft.com/de-de/dotnet/csharp/language-reference/keywords/using-statement Wie man eine Textdatei schreibt wird gut in der Dokumentation dargestellt: https://docs.microsoft.com/de-de/dotnet/csharp/programming-guide/file-system/how-to-write-to-a-text-file Ich würde dir raten, dich mal mit Google und der .NET Dokumentation bzw. der C# Referenz zu beschäftigen.

Edit Sry nvm. Habs überlesen

Wäre .Equals nicht besser, als den Content einfach mit ToString zu wandeln? Dann lernt er auch den Unterschied zwischen == und .Equals

Wenn du schon so genau hinsiehst, dann bitte auch überprüfen, ob der Key nicht bereits der HashMap hinzugefügt wurde^^ Edit: btw wenn du ne HashMap aus Performancegründen willst => bei so geringen Datenmengen bringt das gar nichts...

this.startTime = DateTime.Now; txtStart.Text = startTime.ToString("HH:mm:ss"); Button btnstart = new Button(); btnstart.Content ="Start"; this.btnStart.Inlines.Add(btnstart); Timer.Add(new Timer() { Start = txtStart.Text, Ende = txtEnde.Text }); txtStart.Text = string.Empty; txtEnde.Text = string.Empty; Was soll das hier sein? Warum erstellst du einfach einen neuen Button? Der Button macht hier überhaupt nicht...hat keine Funktion, nada. Außerdem setzt du den Text von txtStart erst auf Datetime.Now und dann auf string.Empty...ist doch klar, dass die TextBox leer ist. txtEnde setzt du auch nirgendwo. Ich weiß nicht, warum du diesen Weg gehst. Du lernst es von grundauf falsch. Warum hast du eine ObservableCollection von Timern, die aber nirgends verwendet wird. Und warum überhaupt eine ObservableCollection, wenn du nicht mit der UI interagierst, eine List würde es hier auch tun. Wenn du einen Prototyp bauen willst, dann mach es mit WinForms...da ist es ok SO zu arbeiten. Du nutzt hier aber eine andere Technologie wie WinForms und das ist einfach falsch. Edit: Bist du Azubi oder Gelernter der ein neues Feld lernen will? Kann ich aus den anderen Threads nicht schließen

Darf man fragen wozu das Ganze ist? Willst du für einen Job WPF lernen? Oder willst du gar ein kleines Portifolio aufbauen? Weil dann solltest du evlt. nicht damit anfangen es falsch zu lernen...

Möchte hinzufügen: Wenn man schone eine Ausbildung hatte, dann gehts auch. Wurde mir jedenfalls angeboten.

@OkiDoki das Problem hierbei ist wohl, dass es keine offizielle Definition von Junior, Software - Steinzeit Entwickler gibt.

Hast du gerade erst angefangen dich in das Framework einzuarbeiten? Wie groß hat man den denn Aufwand eingeschätzt? Ich kann mir auch gut Vorstellen, dass das ein Test ist, schließlich will man dich ja evtl. übernehmen. Gerade wenn man dir keine Hilfe anbietet, will man evlt. sehen wie schnell du dich einarbeiten kannst. Ich habe auch eine Ausbildung in einer Firma gemacht, die sich eingebildet hat, dass ein eigenens Framework ne gute Idee wäre. Hast du es dir schon genau angesehen? Hast du dir angesehen, wie andere Entwickler mit dem Framework arbeiten (sprich den Code von anderen Projekten)? So habe ich angefangen. Nachgesehen, wie einer der besten Entwickler im Unternehmen ein Modul aufbaut und nachgeforscht WARUM er so vorgeht. Auch verstehe ich nicht, dass dir StackOverFlow so gar nicht hilft. Ja ein eigenes Projekt nimmt viel weg, aber die Grundprinzipien der Sprache ändern sich ja nicht.

Ich finde Biden hat einen guten Geschmack

Um das mal ganz grob zu erklären. In WPF hat sich das MVVM Pattern als Best Practice herauskristallisiert und viele Techniken von XAML basieren darauf. View: Die View ist eine XAML Datei, oft eine Page oder ein Window, und sollte im Code-Behind wenn möglich keinerlei Logik haben, besonders keine Logik die mit dem Model oder den ViewModels zu tun hat. Die View wird an ViewModels mittels DataBindings gebunden. ViewModel: Ein ViewModel exportiert Daten zur View. Man könnte sagen es ist eine Abstraktion der View. Alle möglichen Daten abbilden, die du in der View anzeigen willst ODER auch ein Verhalten abbilden mittels Commands. (Deshalb haben Buttons die XAML Property Command). Model: Das Model sind generell die Daten die du in der WPF Anwendung generell zur Verfügung stellen willst. Hier sind alle Properties z.B. deines User Objects definiert (für ein entsprechendes ViewModel benötigst du ja evtl. nur eine Property von hier z.B. Name). Im DataContext eines UserWindows ist also ein UserViewModel, welches Daten verwendet die aus dem bereitgestellten User-Objectes aus dem Model kommt. // Model public class User { public int id { get; set; } public string Name { get; set; } } // ViewModel public class UserWindowViewModel { private readonly _user; public UserWindowViewModel(User user) { _user = user; } public string Name => _user.Name; } // Window Anzeige Window userWindow = new Window(); userWindow.DataContext = new UserWindowViewModel(); userWindow.ShowDialog(); // TextBlock im Window <TextBlock Text="{Binding Name, Mode=OneWay}"/> Das ist aaaaaabbbberr eine sehr vereinfachte Darstellung. Meist nutzt man für MVVM heutzutage eher Frameworks wie z.B. PRISM, MVVMCross oder ReactiveUI. Würde dir empfehlen mal das Beispiel von MVVMCross anzusehen https://www.mvvmcross.com/documentation/tutorials/tipcalc/a-wpf-ui-project

Wie jetzt...Windows Forms oder WPF? Wenn du WPF machst, dann macht man sowas über MVVM und nicht über Events. Da sollte die Oberfläche komplett von der Logik getrennt sein. Windows Forms Anwendungen sind meistens Event-Basiert, während bei WPF in 99% der Fälle MVVM verwendet wird. Du versuchst hier eine WPF Anwendung wie eine Windows-Forms Anwendung umzusetzen.