WPF - Warum?

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).

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

WPF ist UNNÖTIG