Support, Anregungen, Wünsche zur Tutorialreihe <WPF lernen/>

Jeiss schrieb:

Hab aber mal kurz die Windows Ressourcen auskommentiert

Schon mal auf OK geklickt? Ich denke wenn die Resourcen auskommentiert sind wird dir VS den Knoten "Window.Resources" NEU erstellen.

Probiers einfach, ich glaube auch da funzt Undo (STRG + Z).

Grüße
Sascha

Jeiss schrieb:

waren die zwei Zeilen im "Kopf"

Das oben nennt man Namespaces. Und die Zeile die du gepostet hast ist für den DesignTime Support.
Einfach damit man zur Designzeit (also im Editor von VS) auch Daten sieht. z.b. kann man dann gut erkennen ob man die Bindings korrekt gesetzt hast. Ausserdem hat man dann Intellisense beim Binden.

Jeiss schrieb:

Und hab dann ein bisschen über ignorable gegoogelt. Habs nicht ganz verstanden

Ne, wenn du das nicht brauchst lass d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type local:DataTemplate}}" einfach weg. Besser aber du passtg es an.
Wenn dein Window MainWindow heisst dann so: d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type local:MainWindow}}"

Aber... hierzu muss man erstmal verstehen wie das ganze funktioniert, das kommt aber in späteren Kapiteln, also ein wenig Geduld.

Aber was mir viel wichtiger zu sein scheint, ist im Code behind vom DataTemplate Window die kurze Zeile

Ja, da dieses Beispiel weder MVVM noch ein anderes Pattern verwendet um alle hier einfach zu halten, es geht ja um Templates und nicht um Code, wurde der DatenContext des Windows an sich selbst gebunden.
Me.DataContext = Me bedeuted. Wenn du im CodeBehind ein Property mit dem Namen "Test123" hast kannst du im XAML mit Text={Binding Test123} binden.

Hoffe das ist soweit klar.

Grüße
Sascha

Jeiss schrieb:

Für mich war bis jetzt der Namespace in XAML nur die erste Zeile.

Naja, fast. Alles was in etwa so ist xmlns:xyz="blablabla" is die Angabe eines Namespaces.
Wie z.b. xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" oder eben xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
Und nach Angabe des letzterem kann ich d dann verwenden!! und Habe die Properties aus dem d Namespace wie z.b. d:DesignHeight="300" d:DesignWidth="300"

Hoffe jetzt wird es klarer.

Jeiss schrieb:

Wenn man also selber kein so ein "schlaues Köpfchen" ist. Und auch nicht das Glück hat solche aus einem Forum, oder so zu kennen, dann hilft einem die IDE nicht indem "d:DesignInstance" automatisch hinzugefügt wird. Sondern das muss man sich jedes mal "händisch" (gibt es das Wort in der deutschen Sprache....?) im XAML code hinzufügen. Oder?

Na, meines Wissens nach kann der Designer das nicht generieren. Manche Dinge muss man Händisch erledigen.

Jeiss schrieb:

Was wäre denn eine "äquivalente" XAML-Variante für eine so "simple" Bindung "à la" Me.DataContext = Me

Ich überlege gerade, ich denke rein in XAML wird das gar nicht gehen. Und kannst an eine Windowklasse erst im Loaded Eventhandler Binden da du sonst lauter Exceptions um die Ohren geworfen bekommst. Aber dafür gibt es andere Möglichkeiten. Bitte denke über diese Art der Bindung jetzt nicht so viel nach. Wie gesagt, schau mal ins Inhaltsverzeichniss, da kommst noch viel.
Das nächste Tutorial sind z.b. Namespaces. Welch Zufall !!!!
Deshalb, ein wenig Geduld, dein Kopf wird schon noch genug rauchen!

Grüße
Sascha

Hallo

exc-jdbi schrieb:

Daher muss das Model auch folgende Funktionen umsetze können.

Ich nehme an du hast dich vertippt. Du meintest ViewModel oder?

exc-jdbi schrieb:

Die Praxis zeigt aber auch, dass es Situationen gibt, wo die Model-Schicht nicht gebarucht wird. Das ist meistens dann der Fall, wenn die Daten mit einem Service in Verbundung gebracht werden.

Die Praxis zeigt das man eher mehr Schichten benötigt als weniger. Klar, bekomme ich die Daten von einem Webservice kann ich die eigendlich die Model-Schicht weglassen, in der Praxis hat man aber in einer Anwendung irgendwann so viel Logik das das ViewModel augebläht ist und mann macht eine Bussinesslogic dazwischen. Oder je nachdem wie man Daten bekommt sogar vor die Businesslogic noch einen DataAccessLayer.

Grüße
Sascha

Hallo

Ich denke du vertauscht hier etwas. Das Model beschreibt deine Datenstruktur.
Dann hast du dein ViewModel. Das ViewModel gibt die Daten an die View über Binding.
z.b. hast du im Model "Auto" das Property PS. Im ViewModel willst du das der User sowohl die PS als auch die KW eingeben kann. Je nachdem was er für Daten zu Verfügung hat.
Gibt der User 73 KW ein wird im View bei PS 100 PS angezeigt. Gespeichert wird auch in PS, weil du hast im Model ja nur ein PS Property.

Das bedeutet das du KW ja auch validieren musst. Klar kannst du das Model auch Validieren, aber du machst es im viewModel auf jeden Fall auch weil du ja prüfen musst ob korrekte Daten im ViewModel sind bevor du diese ins Model transferierst.
INotifyPropertyChanged hat im Model keinen Sinn. Warum? Im View werden Eigendschaften den ViewModels angezeigt (Binding). Die WPF muss also benachrichtigt werden wenn sich eine dieser Eigenschaften ändert. Aber es muss nicht Benachrichtigt werden über Eigenschaften aus dem Model, warum auch, das View hat nix mit dem Model direkt zu tun. Ergo muss INotifyPropertyChanged in die Basisklasse des ViewModels.

Ich versuche immer im Model so wenig Logik wie nur irgendwie möglich drinnen zu haben, aus dem einfachen Grund weil ich genau wissen möchte wo ich Logik zu suchen habe. Habe ich Logik an mehreren verschiedenen Stellen verteilt über mehrere Layer suche ich jedes mal auf neue wo jetzt was gemacht wird. Das Model Beschreibt im Grunde nur dein Datenmodell (wie der Name schon sagt).
Es gibt sehr viele Ansätze im Model diverse Logik zu implementieren und dort alles mögliche zu unternehmen, bin aber kein Freund davon da ich gerne (wenn ich die Layer schon Trenne) auch meine Logik trenne.

Grüße
Sascha

@exc-jdbi ich sage jetzt auch nicht das es völlig Falsch ist. Was ist schon Falsch und was Richtig?

Hast du sehr wenig Logik und willst es einfach halten, kann es sinn machen da du es im ViewModel einfacher hast.

Beispiel:
Ich habe ein Autohaus mit Eigenschaften wie Adresse, Name usw. und auch eine Eigenschaft Autos mit einer Collection(of Auto).
Auto hat wieder eigenschaften wie Marke, Modell, PS usw.

Korrekt müsstest du jetzt zwei ViewModel`s machen. Ein AutoHausVm und ein AutoVm.
AutoHausVm enthält Properties wie Adresse, Name usw. und ein Property Observablecollection(Of AutoVm)
AutoVm enthält Properties wie Marke, Modell, PS usw.

Alternativ (wenn man wirklich INotifyPropertyChanged im Model drinnen hat) kann man ja auch NUR mit einem AutohausVM auch auskommen.
AutoHausVm enthält Properties wie Adresse, Name usw. und ein Property Observablecollection(Of Auto)
Du sparst dir also das AutoVm. Benötigst aber im View einen Verweis auf das Model und bist bei weitem nicht so flexibel. Du kannst nämlich nur genau die Eigenschaften anzeigen welche im Model enthalten sind, nicht mehr nicht weniger. Musst also dann viel mehr mit Convertern Triggern usw. im View arbeiten.

Wenn du noch fragen hast frag ruig.

Grüße
Sascha

ErfinderDesRades schrieb:

Sieht iwie redundant aus, und ob das in jedem Falle einen Gewinn bringt kann man (ich zumindest) in Frage stellen.

Wer sagt das MVVM in jedem Falle gut ist?
Auf den ersten Blick ist es Redundant - ja, bei näherer Betrachtung ist von Redundanz keine Rede mehr. Wenn man es so vergleicht schon, weil in diesem Beispiel ein und die selben Props vorhanden sind, was in der Praxis sehr, sehr selten der Fall ist.
Aber das steht ja jetzt gar nicht zur Diskussion, das ist nun mal MVVM und ob dir das jetzt gefällt oder nicht musst du für dich entscheiden. Genauso wie jeder andere.
Doch du kannst gerne einbringen wie DU dir das vorstellen würdest (ohne die Trennung aufzugeben).

Grüße
Sascha

Hallo Leute

Da ich leider etwas zu tun hatte dauerte es diesmal ein wenig länger. Aber heute ist es soweit und ich konnte schnell ein neues Video Aufnehmen.
Ich habe diesmal versucht es schnell zu erstellen. Die Techniken sollten ja nun bereits bekannt sein.

Viel spaß damit

Hier gehts zum letzten Tut!

Schöne Grüße
Sascha

@vb_fan Das ist richtig. Ich persönlich finde XAML Code aber übersichtlicher und schlanker.
Hast du mal versucht ein solches Control inkl. Animation in reinem Code zu bauen? Das ist sicher nicht ganz so übersichtlich denke ich.

Wollte damit eigendlich nur darauf Hinweisen das man hierfür eben auch keinen Code benötigt damit jeder weis, wir Arbeiten noch/wieder rein in XAML.

Grüße
Sascha

Hallo @Akanel

Danke erstmel für dein Lob.

Ich weis, leider hänge ich etwas hinterher. Ich habe die nächsten zwei Kapitel auch bereits vorbereitet, komme nur leider nicht dazu das Video schnell zu machen da ich im Moment auch ein wenig eingespannt bin. Das wird sich aber wieder bessern, so viel kann ich bereits sagen.

Was dein Einwand mit "Semmel" angeht, ist witzig das du Semmel verstehst, aber viel unterschied ist ja nicht, mach spricht es nämlich wirklich so aus.

Extensible Application Markup Language, oder XAML ("xsämmel" ausgesprochen), ist eine von Microsoft entwickelte XML-basierte Markupsprache.

Quelle: msdn.microsoft.com/de-de/library/cc295302.aspx

Keine Angst, meine Tastatur ist noch heile . Wenn es stört werde ich mal sehen ob ich das mit meinem Micro besser hinbekomme das mana das nicht so hört.

Grüße
Sascha