Hallo,

dass Kaxaml dir das x:Class-Attribut anmeckert ist klar, das Programm kennt deine Codebehind-Datei nicht. Wenn du das Attribut entfernst, sollte alles dargestellt werden. Wenn das klappt, dann liegt der Fehler im Codebehind.

Warum steht dein Window-Element überhaupt auf Zeile 3? Sollte es nicht eigentlich Zeile 1 sein?

Grüße

Selbst wenn das Laden so funktioniert, die GUI bekommt es [vermutlich] gar nicht mit, dass sich der Variablenwert geändert hat. Siehe dazu auch INotifyPropertyChanged-Interface. Generell sieht der Code sehr eigenartig aus, warum ist z. B. diese Liste statisch?

Methode1 gibt hat als Rückgabewert Dictionary2

Damit zeigt deine Dictionary1 Variable auf das selbe Objekt. Value Types and Reference Types

Hallo,

was du erreichen möchtest macht man mit Attached Properties.

Gruß

Dazu braucht man keine eigene Klasse, Attached Properties reichen dazu schon.

Dieser Fehler klingt danach, als ob du das Fenster mit Show() statt mit ShowDialog() anzeigst.

Und außerdem implementiert die Service-Klasse (zumindest im Snippet) das Interface nicht.

Hallo,

in objektorientierten Programmiersprachen gibts so etwas wie "eine Klasse ausführen" nicht. Zum Testen von Klassen lieber auf Unit-Tests zurückgreifen. Die können immer wieder, mit vorgegebenen Parametern und völlig automatisiert ausgeführt werden. Siehe dazu auch [Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio.

Grüße

Hallo,

Supports MVVM for suggestions.

DataTemplate for suggestions.

Damit hast du alles was du brauchst, um so eine Liste zu erstellen. Hier ist auch ein kurzes Beispiel, wie man Listeneinträge in WPF gruppieren kann.

Grüße

Hallo,

schau dir mal diesen Artikel an. Das sollte eine ganz gute Grundlage bieten.

Grüße

Das Layouting funktioniert in WPF (zum Glück) nicht mehr so wie bei WinForms. Ich finde es hat eher (entfernt) etwas vom Layouting in HTML. Während Panels in WinForms eher optional (und ein Folterwerkzeug) waren, sind sie in WPF für flexible Layouts eigentlich unumgänglich. Und da kann es durchaus mal vorkommen, dass ein Element einen Container für sich allein hat.

Je nachdem was man erreichen will, benutzt man eben andere Panels, und ich glaube du hast einfach nicht verstanden was ein DockPanel eigentlich macht (ist nicht böse gemeint, Anchor-Property in WinForms != DockPanel in WPF). Möglicherweise wäre ein Grid (mit entsprechenden Row- und ColumnDefinitions) eher das richtige. Dann noch die Width- und Height-Angaben des eigentlichen Elements weglassen und schon sollte es passen. Das Ankern von dem du sprichst, passiert je nach Container eigentlich implizit, ansonsten (eingeschränkt) über die Vertical- und HorizontalAlignment-Properties des eigentlichen Elements.

Schau dir mal das Tool Kaxaml an. Für schnelle, reine Xaml-Sachen ist es sehr gut, weil du kein ganzes WPF-Projekt haben musst, und du siehst das Ergebnis sofort. Ansonsten hilft nur Ausprobieren, daraus Lernen, in der Doku oder im Internet nachschlagen, vergessen wie du deine WinForms gestaltet hast 😉

Grüße

Wenn du willst dass ein Control seinen Container komplett ausfüllt, darfst du keine absoluten Breiten- oder Höhenangaben machen, was du aber mit dem Setzen des Width-Attributs gemacht hast.

Ab und an ein Blick in die Doku kann auch nicht schaden.

Grüße

Wenn es um die Oberfläche an sich geht, hast du recht, die wird hauptsächlich, oder fast nur, mit XAML beschrieben. Und ich persönlich finde das viel besser, da schneller, bequemer, logischer usw. als das mit C# der Fall ist (wie bei WinForms). Und wenn man einige der grundlegenden Prinzipien (SOLID) der OOP verstanden hat und auch durchzieht, ist auch MVVM keine große Sache.
Gruß

Du kannst einen Style für den TreeViewItem-Typ definieren, mit einem EventSetter für das ensprechende Event (PreviewMouseRightButtonDown oder sowas). Im Eventhandler kannst du dann einfach die IsSelected-Property setzen. Diese Paar Zeilen Codebehind sind völlig okay, ist ja View-Code.

Hallo,

erstelle dir für jede Art von Items eine eigene ViewModel-Klasse, dann kannst du für jede Klasse ein HierarchicalDataTemplate bzw. ein DataTemplate erstellen. In diesem Beispiel wird das gezeigt. Ich würde dir auch raten, für deine Daten ebenfalls lieber Klassen zu erstellen, anstatt mit DataSet & Co. zu arbeiten.

Das Stichwort heißt ItemTemplate.

So auf die Schnelle sehe ich, dass du in deiner Form_C3 im Load- und im FormClosing-Handler unterschiedliche Properties der Settings verwendest. Möglicherweise liegt es daran.

Aber ich glaube es wäre ohnehin besser, das ganze neu zu machen. Tu dir dabei selber einen Gefallen und gib deinen Steuerelementen und Klassen sprechende Namen. Achte insbesondere auch darauf, Daten, Logik und GUI auseinanderzuhalten.

Die DataTemplates von ItemControls musst du nicht nochmal in Item-Elemente verpacken. Lass also beim Template das ListBoxItem weg, dann müsste es eigentlich klappen.

Das kann auch gar nicht funktionieren, da du offensichtlich den DataContext nur einem Label zuweist. Wenn das komplette Window diesen DataContext bekommt, sollte es funktionieren. Das hättest du aber auch selber rausfinden können, dazu gibt es Tools wie den WPF Inspector oder Snoop.

Ich verstehe nicht was du für ein Problem mit dem CommandParameter hast, aber setz doch einfach mal einen Breakpoint in deine Execute-Methode bzw. Lambda-Expression, dann siehst du was da ankommt.

Mach das mit dem "Rückgabewert" lieber so, dass der Command eine Property des ViewModels setzt bzw. ein Event auslöst oder was auch immer. "Übergabeparameter" für den Command würde ich jetzt als Property des VMs machen, ich finde dass das oft sauberer ist, als irgendeinen Wert von der GUI zu nehmen.
Dass die Methode vom zweiten Command nicht aufgerufen wird, klingt für mich so, als ob das Binding nicht stimmt, da sollte dir die Debugausgabe mehr Infos liefern.
Gruß

Du musst die ItemsSource-Property setzen. So ist es aber nicht wirklich ein Binding.
Warum machst du so eine komische Operation mit dem DisplayName? Der ist doch schon ein String, den musst du nicht in einen String konvertieren.

Dazu gibt es noch die

WhenInjectedInto<T>

-Methode. So brauchen die Klassen nicht mit Attributen dekoriert werden, was ich persönlich besser finde.
Gruß

Der Button wird erst ausgegraut, sobald ich auf das Fenster klicke oder das Fenster wieder in den Vordergrund gerät.

Hatte das Problem auch mal. Liegt daran, dass du die Methode vom CommandManager nicht auf dem UI-Thread aufrufst. Siehe auch Dokumentation von System.Timers.Timer, der kann nämlich das Elapsed-Event auf einem Backgroundthread auslösen.

Gelöst habe ich es damit, dass meine Basisklasse für die Commands nicht den CommandManager nutzt, sondern das CanExecuteChanged-Event als Weakevent anbietet. So kann ich das Event für jeden Command einzeln im ViewModel auslösen, was ich aber eher als Vorteil sehe.

Grüße