vb-paradise.de/allgemeines/tip…utorials/board959-wpf-co/

wie - gibts da keinen Thread mit Buch-Empfehlungen?
Wobei ich Wpf-Büchern gegenüber sehr misstrauisch bin, denn imo ist bei Wpf der MVVM-Pattern das A und O, aber ich hab schon Inhaltverzeichnisse durchgeguckt, da wurde über 100te von Seiten aller möglicher Schnickschnack durchgenommen, und vom MVVM keine Spur.

Also ich denk - probier gerne Buch, und lass mich wissen, obs was bringt.
Aber probier auch die Tuts dort, und in den weiterführenden Links sind ja auch teilweise Tuts verlinkt.

Sieh Dir mal DIESEN Thread an...

Mfg.eniking1998

Weiß jemand von euch ob WPF(im benötigten und richtigen Umfang) in diesem Buch abgehandelt wird:amazon.de/Microsoft-Visual-Bas…laus+l%C3%B6ffelmann+2010?

Nach Inhaltsverzeichnis behandeln die Seiten 189 bis 216 eine "Einführung in die WPF".

Hier mal bei Amazon nach Kundenbewertungen: amazon.de/Windows-Presentation…-umfassende/dp/3836219565

Gruß

Das Buch von @Mr.Blade: hab ich mir vor 2 Tagen bestellt Mal kucken wie´s wird

Einen umfangreichen WPF-Teil bietet auch dieses Buch, da hättest du gleich noch Visual Basic:

amazon.de/Visual-Basic-2012-Gr…Profiwissen/dp/3446434291

Ich selbst hab' aber auch das nicht gelesen und kann den Inhalt, auch aufgrund mangels Kenntnissen, nicht beurteilen.

Gruß

@ErfinderDesRades Man muss aber auch sagen, dass WPF bei weitem nicht nur MVVM ist. MVVM ist sehr nützlich und ich verwende es auch immer. Jedoch kann ein WPF Buch trotzdem 1500 Seiten sehr hilfreicher Infos beinhalten ohne dabei MVVM zu behandeln. WPF auf MVVM zu reduzieren ist meiner Meinung nach falsch, da man durch MVVM noch immer nicht die geringste Ahnung hat wie WPF funktioniert, welche Möglichkeiten man zum Stylen etc. hat. Deshalb kann man MVVM auch einfach noch im hinten nach lesen, da es dazu doch wirklich mehr als genug Artikel gibt.

Kurz googlen hilft immer

de.wikipedia.org/wiki/Model_View_ViewModel

@thefiloe:: Tja, sehe ich bisserl anners.
MVVM ist der Architektur-Pattern, der in Wpf zur Verfügung steht. Damit kann man die Funktionalität einer Anwendung ordentlich aufbauen (egal, wie die Oberfläche dazu aussieht), und anners eigentlich nicht.

Ich reduziere Wpf nicht auf MVVM, so wie ich ein Haus auch nicht auf sein Fundament reduzieren täte.

(guck, mehr mussich eiglich nicht sagen, wennman sich den Satz ma richtig durchn Kopf gehen lässt :D)

Eben. Aber bei WPF geht es nun mal aber primär um die View. Und das hast du mit MVVM alleine nicht abgedeckt. Deshalb hat ein Buch, das auf Styles, Templates, Trigger, Basisklassen, Shader, Animationen, Standardcontrols, Visual-/Logical-Tree, etc. eingeht durchaus seine Daseinsberechtigung.

ja, ganz sicher haben so View-Bücher ihre Daseinsberechtigung!
Aber du sagst, MVVM könne man sich auch nachträglich aneignen, wo ich befürchten täte, wenn man erstmal Anti-MVVM anfängt, dass man da sich in ganz schaurige Architektur-Katastrophen verstrickt, wo man dann iwann ganze Projekte in die Tonne treten kann, weils vorn und hinten nicht mehr aufgeht.
Oder man produziert halt zeitlebens ganz undurchdringlichen Holzweg-Dickicht-GurkenCode, weil man weißes ja nicht, dass und wie es auch anners geht.

Und dasses bei Wpf primär um den View geht, täte ich abstreiten, oder zumindest als Ansichtssache bezeichnen: Ich fasse "Präsentation" auf als etwas, was die Brücke schlägt zwischen Daten und Oberfläche. Daher gehts bei Wpf nicht primär um die View, sondern ebenso schwerpunktmäßig auch um Databinding (das ist nämlich die Brücke), und also MVVM.
Eine noch so kunstvolle Oberfläche ohne diesen Brückenschlag ist gänzlich sinnlos, während umgekehrt auch eine erbärmliche Oberfläche sinnvoll ist, wenn sie auf einer ordentlichen Funktionalität aufsitzt.

Deshalb bezeichne ich MVVM als das Fundament, und die ganzen View-Bücher kannste auch im Nachhinein nachlesen - so rum

---

Guggetmol WPF-TicTacToe - dassis ein ich finde hübsches Beispiel für MVVM-Denke.
Man sieht deutlich, wie Styling und Pipapo erst auf dem Fundament des BindungsSystems so richtig loslegen (das in post#2 gezeigte ist ja nur ein erster Anriß).

Unds gibt dort sogar einen weiterführenden Link auf ein TicTacToe per CodeBehind, was auch funktioniert.
Hier sieht man deutlich, dasses für dieses einfache TicTacToe noch gradma so geeeht, aber man sieht auch: "viel mehr geht bald nicht mehr."
ZB wollteman das CodeBehind-TicTacToe auch mit Numerierung der Züge, oder Markierung der Gewinnzüge ausstatten, müssteman noch einigen weiteren Code schreiben, und zusätzlich jeden der 9 Button mit dem Brimborium ausstatten, wassich nur dem Template meines TicTacToe-Buttons angetan hab.
Der Zusatz-Weiter-CodeBehind-Code wäre erheblich komplizierter - da wäre nämlich im VisualTree der Buttons drin rumzupfuschen, dasses nurso rappelt.
Oder man müsste die Ellipsen und Zugnummern alle als benamte Controls einfügen, und hätte zu den 9 benannten Buttons nun noch weitere 18 benannte Elemente im Codebehind rumzufahren (und jetzt machma ein 4*4-TicTacToe ).
Also die Weiter-Entwicklung des CodeBehind-TicTacToe würde direkt in den og. Holzweg-Dickicht-GurkenCode hineinmarschieren.

Und da sehe ich halt die Gefahr, wennman Anti-MVVM anfängt, und die Erarbeitung des Fundaments auf später vertagt: Dass man in solche Holzweg-Dickichte hineinmarschiert - und u.U. ühaupt nicht mehr rauskommt, weil: man kommt ja auch so vorwärts, so das subjektive Gefühl.