WPF - Warum?

[Dravere]

CSL schrieb:

Noch nie was von Beispielen gehört?

Doch und ich habe es auch als Beispiel aufgefasst. Nur ist das Beispiel schlecht. Du redest von Vorteilen von WPF und ich habe dir klipp und klar aufgezeigt, dass dieses Beispiel keinen Vorteil von WPF aufzeigt.

CSL schrieb:

Dravere schrieb:

Layout-Manager hätten schon von Anfang an drin sein sollen. Dieses Konzept ist URALT!

Was hat das mit meiner Aussage zu tun?
Die Firma Microsoft hat intern entschieden was wo wie zu machen ist, da spielen Faktoren eine Rolle die wir nicht einsehen können. Entsprechend können wir da nicht mit reden.

In dem Punkt reden wir uns wohl irgendwie aneinander vorbei. Du hast gesagt, dass eine wesentliche bessere Sache an WPF die Layout Manager ist. Ich sagte nur, dass es beschämend für Microsoft ist, dass sie sowas nicht bei den WinForms drin hatten. Egal ob WinForm weiterentwickelt werden oder nicht. Zudem gibt es Bibliotheken Dritter, welche Layout Manager nachliefern. Habe somit mühe, dies als grossartiger Vorteil von WPF gegenüber WinForms anzusehen.

CSL schrieb:

Und wenn es einmal kurz Klick gemacht hat begreift man sofort wie simpel das ganze ist.

CSL schrieb:

Und das was in WPF kompliziert wird (wegen der Komplexität), wird in Forms noch komplizierter.
In WPF bekommt man ja wegen der Schachtelung und Stylings viel an die Hand sodass es einfacher wird.

Stylings sind nett, brauchen aber eine Menge an Wissen. Zudem grenzen sie schnell an ihre Grenzen, wo man dann auf Templates zurückgreifen muss. Und Templates habe ich bisher einfach nur als Folter kennen gelernt, da man nicht einfach Standardverhalten abändern kann. Bzw. man muss dann Templates per Copy&Paste übernehmen und darin Dinge abändern gehen. Und das sind zum Teil riesen Quellcode Mengen.
Wie gesagt, bisher hatte ich einfach deutlich weniger Probleme mit WinForms. Vieles ist für mich irgendwie intuitiver. Ich denke schon, dass ich das Prinzip von WPF verstanden habe, aber mir gefällt die Umsetzung nicht. Ich empfinde es als zu aufgebläht, zu kompliziert, zu umfangreich, zu seltsames Standardverhalten.

Gerade heute hatte ich wieder so ein Problem. ListBox gemacht, wo ich für jedes Item eine ProgressBar haben wollte. Die Items werden nämlich der Reihe nach abgearbeitet und wollte für jedes während der Bearbeitung den aktuellen Status anzeigen. Also ItemTemplate + DataTemplate + Panel + ProgressBar ... und dann ist das nur so ein kurzer mikriger Balken, obwohl die ListBox deutlich breiter ist. Wenn ich das Item selektiere, dann ist auch ein breiter Balken selektiert, nur ist die ProgressBar nur ganz kurz, obwohl ist sie auf Stretch eingestellt habe. Nach suchen und suchen kam ich dann drauf, dass man in der ListBox HorizontalContentAlignement auf Stretch setzen muss. Für mich nicht verständlich, wieso sowas nicht standardmässig schon gesetzt ist. Das Item geht sowieso über die ganze breite, sieht man ja auch, wenn man es selektiert.
Nun stehe ich aber vor dem nächsten Problem. Wenn ich über den GridSplitter die ListBox vergrössere, wird wie auch erwartet die ProgressBar grösser, doch beim verkleinern, bleibt die ProgressBar zum Teil gross und wird nicht auch wieder klein.

Und genau auf solche Kleinigkeiten stosse ich auch sehr oft in WPF. WPF verhält sich für mich oft nicht intuitiv.

CSL schrieb:

Eventuell machst du was falsch? Was hast du denn versucht was so verdammt kompliziert war?

Von A bis Z, fast alles was ich bisher probiert habe. Gibt glaub auch ein oder zwei Thread in diesem Forum, wo ich die Probleme geschildert habe. Einfaches einbinden von Daten in die Controls (OneWay) geht oft noch. Zum Beispiel auch DataBinding in ItemTemplates, damit die Controls die richtigen Werte des Item darstellen. Aber dann DataBinding zwischen Controls oder in beide Richtungen, das klappt bei mir oft nicht. Oder man muss Anfangen Converter zu schreiben usw. usf. was den Code einfach nur aufbläht. Am Ende schreibe ich doppelt so viel, als wenn ich es nur in C# geschrieben hätte.

Aber wie gesagt, dass ist einfach nur meine persönliche bisherige Erfahrung. Ich beschäftige mich nun mehr oder weniger stark seit ca. 6 Monaten mit WPF. Ich werde auch noch nicht aufgeben und mich noch ein wenig weiter darin üben. Ob noch ein weiteres Buch hilft, wage ich zu bezweifeln, ich sollte vielleicht einfach noch ein wenig mehr üben. Aber zum Teil fehlt mir echt die Motivation, weil ich es eben oft einfach als Qual empfinde. WinForms ging auf Anhieb und war kein Problem und an WPF kaue ich und kaue ich und es will mich einfach nicht so richtig überzeugen.
Wie ich schon mal gesagt habe, finde ich WPF eigentlich in den Grundzügen sehr interessant, aber beim Umgang damit habe ich einfach mühe.

CSL schrieb:

Hei, interessante Idee Wie kann ich einen meiner Monitore aufzeichnen?

Gibt zahllose gratis Programme im Inet. Ist schon ein Weilchen her, als ich das letzte Mal sowas benötigt hatte, kann dir somit nichts empfehlen.

CSL schrieb:

Aber meine Seite kennst du ja bestimmt sowieso schon

Gäbe es dazu einen Grund? Falls du wegen deiner Signatur meinst: Ich schaue mir Signaturen so gut wie nie an. Habe sie erst angeschaut, als du diesen Satz geschrieben hast

Grüssli

[EXDW]

Hmm, ich verstehe deine Punkte, und ich kann dich auch verstehen. Aber kann es sein das es eher an dir als an WPF liegt? Nicht böse gemeint!
ZB dieses Vergrößern, Verkleinern Problem. Ich kenne das, und wenn man einmal verstanden hat wieso das so ist ist es auch absolut logisch.

Ich hatte am Anfang auch Sachen wo ich dachte "Hä, wieso macht der das so", aber wenn es, wie gesagt, einmal klick gemacht hat, weiß man sofort "Na klar, is ja logisch".

Ich entwickel WPF sei September 2008 intensiv, und ich habe mittlerweile keine Situationen mehr wo ich das verhalten nicht verstehe.
Meist ist es sogar so das ich die Komplette UI nur in Xaml und Code aufbaue, und es ist auf Anhieb so wie ich es erwarte, da ich das verhalten bereits voraussagen kann.
Ich weiß nicht wann mein "aha" Moment war, muss auch so nach ein Paar Monaten gewesen sein.

Ich wüsste kein verhalten was nicht logisch erklärbar ist, warum etwas sich verhält wie es sich verhält.

Ich wollte auch noch anmerken das ich jederzeit meine Hilfe anbiete, sofern erwünscht, per Mail bin ich rund um die Uhr erreichbar.

Meine Website dachte ich kennst du da ich ein Paar Controls public habe (Tulipa und Dianthus) ohne die ich nicht mehr Leben könnte :D,

War aber vermutlich zu eingebildet ^^

[Dravere]

CSL schrieb:

Hmm, ich verstehe deine Punkte, und ich kann dich auch verstehen. Aber kann es sein das es eher an dir als an WPF liegt? Nicht böse gemeint!

Ich würde sagen beides. Ich habe nun schon mit vielen verschiedenen GUI Frameworks gearbeitet. Bisher kam ich in den meisten relativ schnell rein. WPF habe ich auch schnell in den Grundsätzen verstanden, aber ansonsten ist es einfach nur mühsam. Das ist für mich ein Indiz, dass WPF nicht sehr anfängerfreundlich ist und auch eher ein wenig kompliziert. Ich verwende/implementiere auch meistens eher schlichte und einfache GUIs, da wirkt WPF gegenüber WinForms halt sehr aufgebläht. Und ich bin auch kein Designer, kann mich also nicht wirklich an den zusätzlichen Design Möglichkeiten von WPF erfreuen

Ich muss sogar gestehen, dass ich im allgemeinen gar nicht gerne GUIs mache. Daher habe ich schon allgemein eine Abneigung gegen GUIs und wenn es dann einfach nicht klappen will, wird es bei mir schnell zur Frustration

CSL schrieb:

Ich wüsste kein verhalten was nicht logisch erklärbar ist, warum etwas sich verhält wie es sich verhält.

Logisch erklärbar ist alles ... ehm, fast alles
Die Frage ist eben eher, ob es intuitiv ist. Bei einer Bibliothek ist immer wichtig, wie das Standardverhalten ist. Sehr schönes Beispiel, welches ich letztens gesehen habe, ist die neue Boost.Log Bibliothek:
http://permalink.gmane.org/gmane.comp.lib.boost.announce/257

Die Bibliothek scheint sehr flexible zu sein. Bietet viele Möglichkeiten an. Aber die erste "Critical Issue" ist das fehlende oder schlechte Standardverhalten.

CSL schrieb:

Ich wollte auch noch anmerken das ich jederzeit meine Hilfe anbiete, sofern erwünscht, per Mail bin ich rund um die Uhr erreichbar.

Ich werde eher das Forum benutzen
Danke trotzdem.

Grüssli

[EXDW]

Vielleicht ist dein Problem das du noch zu sehr das Forms denken hast, WPF ist nunmal eine komplett andere Technologie, die hat auch sein anderes Standard verhalten welches man kennen lernen muss.

Jedes WPF Control hat seine Defaults, und wenn man das weiß, und weiß was Controls intern Benutzen, dann ist das verhalten auch logisch erklärbar.

Bei zusätzlichen Libraries wär ich vorsichtig, ich habe schon Controls gehen mit Tausenden von Zeilen Code, nachdem ich aber mal genauer hin sah war zu erkennen das das Selbe verhalten in ein Paar Zeilen zusammen gefasst werden konnte. Was ich damit sagen will, nur weil du eine komplizierte Lösung siehst, heißt das noch lange nicht das es auch so kompliziert sein muss.
Innerhalb des .Net Frameworks ist alles schon recht konsistent, zb das Controls in Panels per Default Links ausgerichtet werden.
DockPanel = Links
Grid = Links Oben
StackPanel = (Horizontal) ? Links : Oben

Nur so als Beispiel.

Das Bringt mich direkt zu deinem "Fehler" mit der ProgressBar

Dravere schrieb:

Gerade heute hatte ich wieder so ein Problem. ListBox gemacht, wo ich für jedes Item eine ProgressBar haben wollte. Die Items werden nämlich der Reihe nach abgearbeitet und wollte für jedes während der Bearbeitung den aktuellen Status anzeigen. Also ItemTemplate + DataTemplate + Panel + ProgressBar ... und dann ist das nur so ein kurzer mikriger Balken, obwohl die ListBox deutlich breiter ist. Wenn ich das Item selektiere, dann ist auch ein breiter Balken selektiert, nur ist die ProgressBar nur ganz kurz, obwohl ist sie auf Stretch eingestellt habe.

Zum einen, siehe meine Auflistung Oben, Panels haben Defaults wie sie präsentiert werden.
Zum anderen, im Template eines ListViewItems wird
<ContentPresenter HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" VerticalAlignment="{TemplateBinding VerticalContentAlignment}" SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}"/>
geschrieben, dh HorizontalAlignment wird gebunden, und zum wohle der Konsistenz ist es per default nunmal Links.
(Ich z.b. Stretche nur in 1 von 3 ListViews, einfach weil ich meistens kein Stretch brauch).

// WPF ListBox Problem Beschreibung entfernt, wird hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-267307.html behandelt.

[Dravere]

CSL schrieb:

Jedes WPF Control hat seine Defaults, und wenn man das weiß, und weiß was Controls intern Benutzen, dann ist das verhalten auch logisch erklärbar.

Merke: Ich sage nichts dagegen, dass man nicht alles logisch erklären kann. Ich sage nur, dass die Defaults (die Standardwerte) nicht intuitiv sind. Das ist etwas ganz anderes!

CSL schrieb:

Bei zusätzlichen Libraries wär ich vorsichtig, ich habe schon Controls gehen mit Tausenden von Zeilen Code, nachdem ich aber mal genauer hin sah war zu erkennen das das Selbe verhalten in ein Paar Zeilen zusammen gefasst werden konnte. Was ich damit sagen will, nur weil du eine komplizierte Lösung siehst, heißt das noch lange nicht das es auch so kompliziert sein muss.

Du bringst hier zwei Dinge durcheinander.
1. Ich sagte, dass es Layout Manager für WinForms von Dritten gibt. Die sind gut, funktionieren gut, alles perfekt. Wenn der Code von Dritten so schlecht wäre, dürfte ich auch in keinem Fall jemals deine Controls ausprobieren
2. Das mit der grossen Anzahl an Zeilen Code, wo es sehr kompliziert wird, betrifft die Templates. Wenn du für ein Control ein eigenes Template erstellen willst, welche nur leicht vom Standardverhalten abweicht, dann musst du das ganze Template neu in XAML schreiben. Du kannst nicht nur einzelne Dinge des Standardtemplates abändern.

Grüssli

[EXDW]

Dravere schrieb:

CSL schrieb:

Jedes WPF Control hat seine Defaults, und wenn man das weiß, und weiß was Controls intern Benutzen, dann ist das verhalten auch logisch erklärbar.

Merke: Ich sage nichts dagegen, dass man nicht alles logisch erklären kann. Ich sage nur, dass die Defaults (die Standardwerte) nicht intuitiv sind. Das ist etwas ganz anderes!

Ich würde sagen es ist Ansichtssache, ich finde die Standardverhalten durchaus intuitiv.

Dravere schrieb:

CSL schrieb:

Bei zusätzlichen Libraries wär ich vorsichtig, ich habe schon Controls gehen mit Tausenden von Zeilen Code, nachdem ich aber mal genauer hin sah war zu erkennen das das Selbe verhalten in ein Paar Zeilen zusammen gefasst werden konnte. Was ich damit sagen will, nur weil du eine komplizierte Lösung siehst, heißt das noch lange nicht das es auch so kompliziert sein muss.

Du bringst hier zwei Dinge durcheinander.
1. Ich sagte, dass es Layout Manager für WinForms von Dritten gibt. Die sind gut, funktionieren gut, alles perfekt.

Und? Zusätzliche Libs gibts für jede Technologie und Sprache, und es kann immer gute und schlechte geben.

Dravere schrieb:

Wenn der Code von Dritten so schlecht wäre, dürfte ich auch in keinem Fall jemals deine Controls ausprobieren

Tust du doch sowieso nicht

Dravere schrieb:

2. Das mit der grossen Anzahl an Zeilen Code, wo es sehr kompliziert wird, betrifft die Templates. Wenn du für ein Control ein eigenes Template erstellen willst, welche nur leicht vom Standardverhalten abweicht, dann musst du das ganze Template neu in XAML schreiben. Du kannst nicht nur einzelne Dinge des Standardtemplates abändern.

Grüssli

Da hast du teilweise recht, es kommt darauf an was genau du ändern willst, durch den ButtonChrome hat man das meiste des Standard Aussehens auch mit sehr wenig Code wieder drin.
Passt wieder zu dem, manche machen es umständlich länger (habe ich ja auch) obwohl es deutlich kürzer geht.

[Dravere]

CSL schrieb:

Und? Zusätzliche Libs gibts für jede Technologie und Sprache, und es kann immer gute und schlechte geben.

Lies nochmals durch, worum es bei dem Satz ging. Du hast da ein paar Dinge durcheinander gebracht. Ich stimme mit deiner Aussage vollständig überein. Ich sagte nur, dass es zusätzliche gute Libs gibt. Das ist schon alles.
Du hast irgendwie die Komplexität von Templates mit der Aussage über Layout Manager bei WinForms durcheinander gebracht. Anders kann ich deine Aussagen nicht verstehen

CSL schrieb:

Ich würde sagen es ist Ansichtssache, ich finde die Standardverhalten durchaus intuitiv.

Und ich nicht
Ich glaube, dass wir es bei dem stehen lassen können

Grüssli

[EXDW]

Sehe ich auch so ja.

Was wolltest du mit dem Thread überhaupt erreichen?

Hier und da gibt es sicherlich noch Bugs, WPF ist ja noch nicht so alt. Und jedes Framework hat zu seinen Anfängen noch ein paar Bugs.

Ich glaube sobald man das WPF-Denken intus hat, versteht man alles auf Anhieb, da es innerhalb des WPF durchweg konsistent und vorhersehbar ist.
Du hast vielleicht nur zu lange Forms gemacht

[Zeus]

Somasegar schrieb:

We continue to invest in WinForms for .NET FX 4. This includes the core expectation of maintaining compatibility for applications already written in WinForms, fixing bugs that developers have reported, contributing to overall developer experiences across Visual Studio, as well as perf work and some feature development.

[Dravere]

CSL schrieb:

Was wolltest du mit dem Thread überhaupt erreichen?

Der Thread ist nicht von mir. Du bringst da wieder was durcheinander.
Der andere Thread drüben ist von mir :p
Dieser hier ist uralt aus dem Jahr 2008 und nicht von mir

Ich bin nur eingestiegen, weil ich der Meinung bin, dass WPF nicht so super toll ist, wie es zum Teil überall hochgejubelt wird. Es ist interessant, aber auch nicht das Gelbe vom Ei

CSL schrieb:

Ich glaube sobald man das WPF-Denken intus hat, versteht man alles auf Anhieb, da es innerhalb des WPF durchweg konsistent und vorhersehbar ist.

Nein, ich denke es ist eher so, dass man das Standardverhalten von WPF lernen muss und vielleicht noch die zahllosen Möglichkeiten eine Aufgabe zu erledigen.

Wie WPF aufgebaut ist und funktioniert, ist etwas speziell, aber man kann es relativ schnell nachvollziehen. Da die Standardwerte einen starken Einfluss auf das Verhalten aller Controls haben wegen den Dependency Properties, muss man diese ganz genau kennen. In WinForms beziehen sich die Standardwerte immer nur auf ein Control, in WPF werden die Werte in der visuellen Hierarchie vererbt.

CSL schrieb:

Du hast vielleicht nur zu lange Forms gemacht

Nö, ich programmiere schliesslich erst seit ca. 1,5 Jahren C#. Allerdings habe ich davor natürlich mit anderen Frameworks gearbeitet und mit der WinAPI. Das hat schliesslich durchaus Ähnlichkeiten. Vielleicht liegt es wirklich daran, keine Ahnung.

Zeus schrieb:

Somasegar schrieb:

We continue to invest in WinForms for .NET FX 4. This includes the core expectation of maintaining compatibility for applications already written in WinForms, fixing bugs that developers have reported, contributing to overall developer experiences across Visual Studio, as well as perf work and some feature development.

Freut mich zu hören. Kannst du auch noch die Quelle dazu angeben?

Grüssli

[Zeus]

Von Hier
http://ctlabs.blogspot.com/2010/04/visual-studio-2010-net-40-and-winforms.html

Via:
http://blogs.msdn.com/somasegar/archive/2008/11/12/net-fx-4.aspx

Ops ist ein Kommentar von Matt Gibbs, Development Manager – UI Framework and Services – Microsoft

[Fedaykin]

Ich habe mir WPF bisher noch nicht genauer angeschaut, schon daher da ich die Zeit gar nicht habe und bei meinen aktuellen Aufgaben, andere Anforderungen gestellt werden.

Allgemein wirkt es sehr Solide. Leider bewegt es sich durch von der Kernprogrammiersprache C# durch das XAML Prinzip weg.

Eigentlich würde es mir schon fast reichen wenn man so schön einfach wie in Java die Controlls per Layoutmanager "per Hand" Programmieren könnte. Der Rest von WPF ist eher ein Dependency Injection Framework mit GUI Feature (Zumindest das was ich so spontan gesehen ab. Ob mein Urteil da wirklich richtig ist weiss ich nicht).

Kann man das eigentlich dafür auch missbrauchen? Anstatt seine GUI damit aufbauen wirklich Klassenabhängigkeiten nur durch XAML beschreiben? Das würde es nämlich für mich weitaus interessanter machen. Oder gibt es andere richtige Dependency Injection Frameworks wie Spring für Java?

[EXDW]

[quote="Dravere"]

CSL schrieb:

Was wolltest du mit dem Thread überhaupt erreichen?

Der Thread ist nicht von mir. Du bringst da wieder was durcheinander.
Der andere Thread drüben ist von mir :p
Dieser hier ist uralt aus dem Jahr 2008 und nicht von mir

Ups, stimmt, lord_fritte wars
Was ich sagen wollte, bei solchen Threads ist es doch klar das es die Fanboys auf den Plan ruft, kann man genauso schreiben "C++ - Warum?"

Dravere schrieb:

Ich bin nur eingestiegen, weil ich der Meinung bin, dass WPF nicht so super toll ist, wie es zum Teil überall hochgejubelt wird. Es ist interessant, aber auch nicht das Gelbe vom Ei

Wir können nur so verbleiben das wir da unterschiedlicher Meinung sind.

Wir entwickeln auch Kommerzielle Applikationen mit WPF und neu entwicklungen sind nun immer in WPF, C++ (MFC) ist nur noch für Legacy.
WPF nehmen wir hauptsächlich wegen der Style Möglichkeit, Forms würde kein Mehrwert gegenüber MFC bringen (Vor allem wo das Wissen vorhanden ist).

[urs32]

Hallo Zusammen,

einige wichtige Argumente sind bei der Diskusion hier noch nicht erwähnt worden und den heutigen Stand der Technik darstellen:
- Startgeschwindigkeit von WPF Applikationen ist langsamer als bei Winforms
- Rescourcenverbrauch ist höher als in Winforms.
- XAML Desiner in VS2010 ist verbesserungswürdig. Ein GUI im Editor zu schreiben ist nicht das was ich von einem modernen User Interface Editor erwarte
- Das Font Rendering ist nicht optimal. Schriften wirken verschwommen.
- Code Debugging ist auch durch das Databinding nicht mehr optimal. Der Debugger zeigt nicht genau wo der Fehler ist.
- Refactoring funktioniert nicht mehr durchgehend. Teilweise sind Databindings in Strings-Ausdrücken und Properties in Strings.

Warum sind MSPaint und Wordpad in Win 7 nicht mit WPF programmiert? Sind ja sowieso neuprogrammierungen im Gegensatz zu MS Office 2010 wo man den alten Code für das nichteinsetzen von WPF anführen könnte.
Ausserdem sehe ich nichts an Win 7 was mit WPF umgesetzt ist.

Wo ist der Vorteil der GUI von vs2010 in WPF gegnüber vs2008 welches noch mit den alten controls programmiert wurde. Ich kann wirklich nichts erkennen?

Grüsse
Urs

[wisser]

WPF ist UNNÖTIG