Grundsätzlich ist es natürlich immer gut, etwas neues zu lernen.
WPF ist übrigens nicht nur für grafisch aufwändige Programme geeignet, sondern auch, wenn man komplexe Steuerelemente haben möchte.
Für wirklich kleine Programme ist WPF nicht empfehlenswert, aber wenn man sehr viele Steuerelemente (die auch gut gelayouted werden sollen) braucht und/oder viel komplexe Bindings haben möchte, dann ist WPF genau die richtige Adresse. WPF ist nämlich durchaus auch sehr funktional und nicht nur auf Grafik ausgelegt.

Auch wenn ich lieber mit WinForms arbeiten würde, WPF ist die Zukunft, bzw. war die Zukunft und sollte mittlerweile die Gegenwart sein.
Da alle jetzt vermutlich mit Argumenten um sich werfen nenne ich nur mein favorisiertestes und das ist das, dass ich einfach Daten, GUI und deren Verbindungen trenne.
Beispiel dafür ist die MVVM Struktur (weiß nicht genau ob es so heißt, aber auf jedenfall ähnlich wie MVC in PHP. Genaueres könntest du in den Beiträgen des Users @theofile erfahren)
msdn.microsoft.com/de-de/magazine/dd419663.aspx

LaMiy schrieb:

Auch wenn ich lieber mit WinForms arbeiten würde, WPF ist die Zukunft, bzw. war die Zukunft und sollte mittlerweile die Gegenwart sein.

Falsch. WPF ist keine Ablösung für WinForms, sondern eine Alternative. Wie Artentus es so schön beschrieb, hat es einen Zweck.
Für jede noch so kleine Anwendung WPF zu benutzen wäre so, als ob du für den Taschenrechner jedes mal die Amazon Cloud zum rechnen benutzt.

Ja lohnt sich zumal du das Zeug was du in WPF lösen kannst nicht wirklich mit Winforms lösen kannst. Ihr seht das etwas falsch. WPF ist genauso wenig eine Alternative zu winforms wie winforms eine Alternative zur Konsole ist. Außerdem ist XAML jetzt wirklich nicht schwer. Wenn man ein paar Dinge kennt, dann ist das wirklich komplett einfach.

WinForms und WPF sind zwei unterschiedliche Dinge. Während das eine hauptsächlich größte Teile der Windows API wrappt um damit sehr schön und OO Win32 zu nutzen, rendert das Andere seine GUI mit DX. Soviel zum Grafischen. WPF ist sehr angenehm zu benutzen während man in WinForms bei Event/Property Bindings und gedönz ohne Codebehind nicht auskommt. Welches von beiden besser ist, lässt sich nicht sagen.

FunnySunny schrieb:

"WinForms ist Crap", "WPF ftw!" oder "WPF ist die Zukunft"

Also so unbegründete Geistes-Blähungen iwelcher Wichtigtuer - sind das für dich Beweggründe, nach denen du dein Handeln konzipierst?

Ich hoffe nicht, weil sonst tätes mir um die Mühe meiner Antwort leid.

Also großes Projekt spricht für Wpf.
Annererseits sagt das ja auch garnix - isses dir vlt. möglich, bisserl näher zu erläutern, welches große Projekt du meinst?

Wenn du sicher bist, das in Winforms abhandeln zu können, und wenn du dich in WinForms auskennst, da sehe ich keinen zwingenden Grund, das nicht auch zu tun. Das ist sicherlich der leichtere Weg, und mit geringerem Risiko, zu scheitern.

Was anneres ists, wenn wpf dich interessiert.
Weil es ist tatsächlich mächtiger als Winforms, und vieles ist sehr genial, und lohnt sich, sich das anzulernen. Und es ist die Zukunft, das sehe ich auch so - womit allerdings WinForms imo nicht gleichzeitig totgesagt ist - das ist, was mich an diesen Geistes-Blähern immer so ärgert.

Aber auch wenn annere meinen, Wpf sei iwie "leicht" - ich finde es sehr schwierig. Man muß VB.Net so ziemlich vollständig beherrschen, also Klassen, Vererbung, Interfaces, Delegaten, Enumerationen, anonyme Methoden - das muss man einfach komplett drauf haben, wenn man in Wpf eine tragfähige Architektur aufbauen will.
Und vom Xaml ist dabei noch kein Wort gesprochen - da gibts auchn Haufen zu lernen.

Wenn ich mir die beiden Programme so ansehe würde ich garantiert WPF verwenden(zumal ich natürlich WPF großteils beherrsche). WPF hat einfach den Vorteil, dass du Designtechnisch aufwendige Dinge recht schnell, übersichtlich und dynamisch gestalten kannst. Dies ist zum einen auf ein klasse Framework, ein klasse Konzept mit Styles, Templates und dynamischen Ressourcen,... zurückzuführen. Andererseits bietet WPF auch einfach Möglichkeiten ins unbegrenzte. Es geht sogar soweit, dass du Effekte welche direkt auf der Grafikkarte laufen erstellen kannst, oder 3D GUI's erstellen kannst(siehe z.B. codeproject.com/Articles/191026/WPF-Elements-Cloud). Aber auch einfache Dinge wie z.B. dass WPF nie verpixelt oder diese hässlichen Ränder hat macht sie zu einem absoluten attraktivem Framework. Natürlich mögen manche GDI Gurus sagen, dass sie auch 3D Effekte etc. mit GDI hinbekommen. Jedoch wird das einfach niemals so. Und alleine diese ganzen Point-Angaben für Location,... und beim Zeichnen von Controls sind in Winforms einfach extrem mühsam. Ich persönlich sehe hier keinen einzigen Grund nicht WPF zu benutzen. Denn Tatsache ist, dass du durch MVVM und Bindings eine sehr stabile Architektur erstellen kannst, welche du in Winforms so übersichtlich und solide fast nicht hinbekommst. Und Designtechnisch habe ich ja schon erklärt, ist WPF Winforms einfach bei weitem überlegen.

Fazit: Ich verwende Winforms bei kleinen GUI's für nen paar Einstellungen, nen paar Häkchen,... etc. Diese GUI's legen aber Wert auf Funktionalität, jedoch aber nicht auf Design, Aussehen, etc. und haben auch keine große Logik oder Datenmenge im Hintergrund. Für alles andere verwende ich WPF(sofern es ne Desktopapp ist). Alleine schon, dass ich keine Timer sondern nur nen paar Zeilen XAML für ne Animation brauch finde ich einfach Klasse!

Es ist deine Entscheidung, doch ich denke ich habe meinen Standpunkt mehr als klar gemacht. Ich muss aber auch dazu sagen, dass ich kein WPF Fanatiker bin. Winforms hat seine Daseinsberechtigung, jedoch meiner Meinung nach nicht bei solchen Projekten.

jo, ich tendiere auch zu wpf.
vor allem, weil wpf ein umfangreiches Konzept von "Document" zu haben scheint.
Also zB die Vorstellung, in einer WinForm-Richtextbox einen Fließtext um ein eingebettetes Bild herumfließen zu lassen gruselt mich. Auch in Wpf habich keine Ahnung, wie das ginge, bin aber optimistisch, dass dafür iwas sehr leistungsfähiges konzipiert ist - nur wie gesagt: mit dem Document-Kram habichmich noch nicht beschäftigt.

Stichwort FlowDocument.

ErfinderDesRades schrieb:

Fließtext um ein eingebettetes Bild herumfließen zu lassen

Die Tatsache, dass es FLOWDocument heißt, stimmt mich ja schon mal positiv :).

Mache bitte nicht den Fehler und benutze WPF nur, weil "es besser aussähe" (stimmt nicht, es läuft am Ende auf eine weiße WinForm auf Segoe UI raus). Allerdings erscheint vieles auf den ersten Blick viel komplizierter als es ist - liegt nicht zuletzt an der stellenweise etwas seltsamen Dokumentation. Davon, und vom gewaltigen Umfang, sollte man sich nicht einschüchtern lassen.

Was du auch nicht vergessen solltest, wenn du dich dafür entscheidest: WPF steckt gewissermaßen immer noch in der Kinderwiege. Vor Allem der Designer zeigt immer wieder Bugs und Anfälligkeiten, von denen man sich nicht irritieren lassen sollte.

Das Konzept von OOP wird in der WPF mittels MVVM meiner Meinung nach fast zur Perfektion getrieben. Natürlich braucht man es nicht für jedes 08/15-Programm, aber wenn es etwas größer wird kommt dir die Übersichtlichkeit sicher zugute.

Es ist ungerechtfertigt, WinForms dafür maßlos fertigzumachen, dass es keine dollen Animationen, Vektorgrafiken und 3D-Spielereien kann - das sind alles keine "must-haves", die Technik ist aber definitiv die Zukunft. WinForms ist ausgereift, WPF noch relativ jung. Es kann also nicht schaden, sich das mal anzusehen.

Dass der WPF-Editor teilweise noch einige Spinnereien besitzt, das lässt sich nicht leugnen. Das ist aber auch halb so schlimm, da du diesen eh nicht wirklich verwenden solltest -> höchstens zur Vorschau. Alles andere geht mit XAML. Das Framework an sich finde ich doch schon recht ausgereift. Es ist sehr, sehr umfangreich und ich habe bis jetzt noch nie wirklich Bugs feststellen können. Es läuft sehr solide und meiner Meinung nach gibt es daran nichts auszusetzen. Ob eine schöne GUI bei einer solchen Applikation must-haves sind, darüber lässt sich streiten. Tatsache ist aber, dass Aussehen mittlerweile sehr, sehr viel zählt und die Benutzer in Zeiten von Touch und den ganzen anderen Spielereien immer mehr Wert darauf legen. Mit ein paar eckigen Knöpfen kannst du dann was Schönheit angeht wenig überzeugen und auch mit GDI kommste da teilweise einfach nicht mehr weit. Und wenn, dann haste rießige GDI Codes durch welche kein Mensch mehr wirklich durch steigt.

Die Leute in Stadtverwaltungen beschweren sich laut meiner Quelle (@nikeee13: :>) über jede kleine Änderung ;). Kommt natürlich drauf an, ob es nachher kalifornische Hipster, deutsche Verwaltungsbeamte oder Kiddys benutzen, dass Animationen Must-haves sind - und ob man sowas unbedingt nachkommen muss, aber das ist eine andere Frage.

Die Spinnereien sind ja auch gar nicht schlimm - und ich soll den WPF-Editor nicht verwenden? Du vermischst da aber jetzt was. Ich tippe alles in XAML, es geht mir darum, dass der Designer teilweise nicht hinterherkommt, schlichtweg unsinnige oder alte Fehlermeldungen anzeigt, sowas.

Lukas schrieb:

Ich tippe alles in XAML

Dassis aber schlechter Stil, tätich sagn. Zumindest, was die Bindings betrifft: Binding-Picking im Xaml-Editor

@ErfinderDesRades: Mit Binding-Picking ist man sicherer unterwegs, dazu bin ich in letzter Zeit ohnehin verstärkt übergegangen. Ob das jetzt unbedingt mit Stil zusammenhängt... kann man drüber streiten.

Was soll daran bitte schlechter Stil sein? Ich schreibe meine Bindings immer selbst. Ich bin mir das gewöhnt und nur in sehr seltenen Fällen verwende ich den PropertyGrid. Wenn man es kann, dann kann man das ja auch ruhig machen. Wenn es nicht kannst, dann ist es gut, dass es das Tool gibt. Aber ich bin da wesentlich schneller als über einen Editor. @ErfinderDesRades
Und, dass der Editor hin und wieder seine Macken hat habe ich ja zugegeben. Mir ist auch das Problem bekannt, dass er teilweise ewig meckert, dass gewisse Elemente nicht vorhanden sind usw. und erst nach 10 mal rebuild drücken gehts usw.

thefiloe schrieb:

Was soll daran bitte schlechter Stil sein?

naja - wie Lukas sagt: mit Binding-Picking bist du sicherer unterwegs.
Und wenn man 2 Optionen hat vorzugehen, eine davon sicherer als die annere, dann ist die annere halt schlechter Stil.

Du programmierst ja auch nicht strict Off, odr?