WPF - Warum?
-
eye-eye schrieb:
Man schreibt "man" nicht mit Doppel-M.
Woher weißt du ob er nicht wirklich den Mann gemeint hat?
Übrigens schreibt man "doppel" nicht großeye-eye schrieb:
Ganz sicher kann nicht jeder Depp eigene Controls schreiben.
Du also auch nicht.
eye-eye schrieb:
Xaml ist eine allgemeine Beschreibungssprache für die Oberflächengestaltung von Anwendungen.
Xaml ist KEINE Programmiersprache.Warum war es wohl in " gehoben
-
CSL schrieb:
1. Man kann alle Controls komplett neu Designen, ist dann wie ein neues Control
2. Man kann alle Controls nahezu beliebig ineinander verschachteln
3. WPF ist per Default dynamisch genug benötigten platz selber zu ermitteln und die UI an zu passen
4. In WPF hat man Animation und sonstige grafischen Effekte schnell zusammen getippt ohne viel aufwand
5. Jeder Depp kann eigene Controls schreiben -> http://www.my-libraries.de/dianthus/previews/ http://www.my-libraries.de/tulipa/previews/Zu 1: Uh toll! Jedes Programm sieht anders aus und ist unbedienbar.
Zu 2: Yeeehaaa! Ich kann eine TextBox in einen Button setzen ... ehm, moment? Was bringt mir das?
Zu 3: LayoutManager ist nicht wirklich was bahnbrechendes. Es ist eigentlich beschämend für Microsoft, dass sie dies nicht schon in WinForms gemacht haben.
Zu 4: Yes! Alles blinkt! Ich bekomme endlich den lang ersehnten Augenkrebs! Zudem ist es oft auch noch sehr langsam und in vielen Ecken unausgereift.
Zu 5: Halte ich für stark untertrieben. Es braucht genau gleich viel wie bei WinForms, bis man eigene Controls schreiben kann. Und dazu kann man kein Depp sein, sondern muss sich zuerst etwas beibringen.Ich halte WPF für sehr interessant, aber auch stark überbewertet. Ich habe nun schon öfter erlebt, dass eine Problemlösung in WPF 10 mal mehr Aufwand benötigt hat als in WinForms. Auch sehen die Beispiele immer so wunderbar aus, wenn man allerdings mit den wirklichen Problemen zu tun hat, dann scheitert die Datenbindung oft ziemlich schnell. Das ist zumindest meine bisherige Erfahrung mit WPF. Wenn man sich in WPF ein wenig mehr eingeschränkt hätte, nicht probiert hätte, alles zu erreichen, dann wäre die Sache wohl deutlich besser geworden. Ich muss zum Beispiel schlicht und einfach keine TextBox in einem Button platzieren können.
Übrigens: Hat keiner bemerkt, dass eye-eye "Doppel-M" geschrieben hat? Halte ich für den viel grösseren "Fail" am Ganzen.
Aja und hat auch niemand bemerkt, dass der Thread aus dem Jahr 2008 stammt? :pGrüssli
-
Dravere schrieb:
Aja und hat auch niemand bemerkt, dass der Thread aus dem Jahr 2008 stammt? :p
lord_fritte du Grabschänder
-
Dravere schrieb:
Zu 1: Uh toll! Jedes Programm sieht anders aus und ist unbedienbar.
Das Programm sieht aus wie der Entwickler es gemacht hat, er hat die Möglichkeit es richtig aber auch falsch zu machen
Dravere schrieb:
Zu 2: Yeeehaaa! Ich kann eine TextBox in einen Button setzen ... ehm, moment? Was bringt mir das?
Du kannst auch ein Image in ein Button packen, oder eine CheckBox in einer GroupBox, gibt viele möglichkeiten
Dravere schrieb:
Zu 3: LayoutManager ist nicht wirklich was bahnbrechendes. Es ist eigentlich beschämend für Microsoft, dass sie dies nicht schon in WinForms gemacht haben.
Es wurde entschieden das Forms nicht weiter gemacht wird, in Firmenentscheidungen kann man von außen nicht mit reden.
Dravere schrieb:
Zu 4: Yes! Alles blinkt! Ich bekomme endlich den lang ersehnten Augenkrebs! Zudem ist es oft auch noch sehr langsam und in vielen Ecken unausgereift.
Siehe Punkt 1.
Zudem, nimm mal ein einfaches Kartenspiel, ist doch schön wenn das austeilen der Karten auch entsprechend präsentiert wird.Dravere schrieb:
Zu 5: Halte ich für stark untertrieben. Es braucht genau gleich viel wie bei WinForms, bis man eigene Controls schreiben kann. Und dazu kann man kein Depp sein, sondern muss sich zuerst etwas beibringen.
Kommt natürlich auf das Control an.
Nehmen wir mal ein Beispiel, Button mit einem Bild.
Ich erstelle eine Klasse, leite von Button und und Platziere (Snippet) ein Image Dependency Property (1-2 Minuten vorbei)
Nun geh ich in den Xaml und definiere ein Style mit einem Template (1 Minute vorbei)
Nun erstelle ich ein Horizontalen StackPanel, platziere dort ein Image und ein Label (1 Minute vorbei)
Nun kann es noch nach eigenen wünschen Gestyled werden (je nach möglichkeit und fähigkeit kurz oder lang)
Fertig.
Nun kann ich immer statt <Button Content="Demo" /> sowas machen wie "<ImageButton Image="MyPicture.png" Content="Demo" />Dravere schrieb:
Ich halte WPF für sehr interessant, aber auch stark überbewertet. Ich habe nun schon öfter erlebt, dass eine Problemlösung in WPF 10 mal mehr Aufwand benötigt hat als in WinForms. Auch sehen die Beispiele immer so wunderbar aus, wenn man allerdings mit den wirklichen Problemen zu tun hat, dann scheitert die Datenbindung oft ziemlich schnell. Das ist zumindest meine bisherige Erfahrung mit WPF. Wenn man sich in WPF ein wenig mehr eingeschränkt hätte, nicht probiert hätte, alles zu erreichen, dann wäre die Sache wohl deutlich besser geworden. Ich muss zum Beispiel schlicht und einfach keine TextBox in einem Button platzieren können. bei WinForms, bis man eigene Controls schreiben kann. Und dazu kann man kein Depp sein, sondern muss sich zuerst etwas beibringen.
Ich arbeite seit ende 2008 mit WPF und ich habe das absolute gegenteil erlebt was du hier schilderst, und wir setzen WPF auch schon kommerziell in unseren Applikationen ein, und www.my-libraries.de
-
CSL schrieb:
Das Programm sieht aus wie der Entwickler es gemacht hat, er hat die Möglichkeit es richtig aber auch falsch zu machen
Und wenn man es richtig macht, sieht es aus, wie ein WinForms Programm? :p
CSL schrieb:
Du kannst auch ein Image in ein Button packen, oder eine CheckBox in einer GroupBox, gibt viele möglichkeiten
Wow, ich kann ein Bild in einen Button reinmachen? Weisst du was unglaublich ist, dass kann man auch mit WinForms machen. Man konnte schon früher Controls auf andere Controls legen. Das meiste was sinnvoll ist, konnte man schon früher schon.
Was ich für wirklich sensationell in der Zusammenstellung halte, sind höchstens die ItemTemplates, wodurch man die Listen sehr schön anpassen kann und sie passen trotzdem zu dem, was man von Windows kennt.CSL schrieb:
Es wurde entschieden das Forms nicht weiter gemacht wird, in Firmenentscheidungen kann man von außen nicht mit reden.
Layout-Manager hätten schon von Anfang an drin sein sollen. Dieses Konzept ist URALT!
CSL schrieb:
Zudem, nimm mal ein einfaches Kartenspiel, ist doch schön wenn das austeilen der Karten auch entsprechend präsentiert wird.
Und es ist deutlich langsamer, als wenn man es mit früheren Mitteln gemacht hat. Ob es wirklich einfacher ist, ist auch so eine offene Frage.
CSL schrieb:
Kommt natürlich auf das Control an.
Nehmen wir mal ein Beispiel, Button mit einem Bild.Das mache ich in WinForms ohne ein Control dafür zu erstellen, der normale Button kann das bereits. Und sobald es halt etwas komplizierter wird, wird es verdammt komplizierter und das über 20 Ecken und Kanten. Das ist auch genau, wie ich es bis jetzt durchgehend erlebt habe. Die einfachen kurzen Beispiele aus den Büchern passen perfekt und sind leicht. Will man etwas aufwendigeres machen, wird es EXTREM aufwendig.
Und auch deine Zeiten, dass möchte ich mal sehen. Mach mal ein Video davon, mal schauen, ob du wirklich einen guten Code in dieser Zeit hinkriegst. Ich denke, dass du da schon einige zusätzliche Minuten benötigst. Aber nicht desto trotz, du hast anscheinend bereits eine Menge an Erfahrung in WPF. Erinnere dich zurück an die Anfänge. Du willst mir nicht sagen, dass du es damals schon einfach so aus dem Ärmel geschüttelt hast?
Ich persönlich habe deutlich schneller gelernt mit WinForms eigene Controls zu erstellen als mit WPF. WPF empfand ich als deutlich komplizierter für sowas. Es ist übrigens etwas, dass nicht mal Microsoft abstreitet, dass es komplizierter ist. Es wird allerdings damit begründet, dass man eben mehr Möglichkeiten hat und Design von Logik deutlich bessern trennen kann.CSL schrieb:
Ich arbeite seit ende 2008 mit WPF und ich habe das absolute gegenteil erlebt was du hier schilderst, und wir setzen WPF auch schon kommerziell in unseren Applikationen ein, und www.my-libaries.de
Die Seite wiederspigelt meine Erfahrung mit WPF:
"Could not locate remote server"Grüssli
-
Dravere schrieb:
Und wenn man es richtig macht, sieht es aus, wie ein WinForms Programm? :p
Man kann in Forms genauso Bullshit machen. Unbenutzbare Programme, gehen mit jeder Technologie.
Dravere schrieb:
Wow, ich kann ein Bild in einen Button reinmachen? Weisst du was unglaublich ist, dass kann man auch mit WinForms machen. Man konnte schon früher Controls auf andere Controls legen. Das meiste was sinnvoll ist, konnte man schon früher schon.
Was ich für wirklich sensationell in der Zusammenstellung halte, sind höchstens die ItemTemplates, wodurch man die Listen sehr schön anpassen kann und sie passen trotzdem zu dem, was man von Windows kennt.Noch nie was von Beispielen gehört?
Dravere schrieb:
CSL schrieb:
Es wurde entschieden das Forms nicht weiter gemacht wird, in Firmenentscheidungen kann man von außen nicht mit reden.
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.Dravere schrieb:
CSL schrieb:
Zudem, nimm mal ein einfaches Kartenspiel, ist doch schön wenn das austeilen der Karten auch entsprechend präsentiert wird.
Und es ist deutlich langsamer, als wenn man es mit früheren Mitteln gemacht hat. Ob es wirklich einfacher ist, ist auch so eine offene Frage.
Deutlich langsamer kann ich nicht sagen, ich habe genau das nämlich schon gemacht, ich ich brauchte dafür nur 18 Zeilen Code (gerade mal nach gesehen). Und wenn es einmal kurz Klick gemacht hat begreift man sofort wie simpel das ganze ist.
Dravere schrieb:
CSL schrieb:
Kommt natürlich auf das Control an.
Nehmen wir mal ein Beispiel, Button mit einem Bild.Das mache ich in WinForms ohne ein Control dafür zu erstellen, der normale Button kann das bereits. Und sobald es halt etwas komplizierter wird, wird es verdammt komplizierter und das über 20 Ecken und Kanten. Das ist auch genau, wie ich es bis jetzt durchgehend erlebt habe. Die einfachen kurzen Beispiele aus den Büchern passen perfekt und sind leicht. Will man etwas aufwendigeres machen, wird es EXTREM aufwendig.
Siehe oben, es ist ein Beispiel. 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.Dravere schrieb:
Und auch deine Zeiten, dass möchte ich mal sehen. Mach mal ein Video davon, mal schauen, ob du wirklich einen guten Code in dieser Zeit hinkriegst.
Hei, interessante Idee
Wie kann ich einen meiner Monitore aufzeichnen?
Dravere schrieb:
Ich denke, dass du da schon einige zusätzliche Minuten benötigst.
In Forms wäre es deutlich länger.
Dravere schrieb:
Aber nicht desto trotz, du hast anscheinend bereits eine Menge an Erfahrung in WPF. Erinnere dich zurück an die Anfänge. Du willst mir nicht sagen, dass du es damals schon einfach so aus dem Ärmel geschüttelt hast?
Doch, meine Animation des austeilen von Karten hatte ich damals in meinem Anfängen geschrieben.
Dravere schrieb:
Ich persönlich habe deutlich schneller gelernt mit WinForms eigene Controls zu erstellen als mit WPF. WPF empfand ich als deutlich komplizierter für sowas. Es ist übrigens etwas, dass nicht mal Microsoft abstreitet, dass es komplizierter ist. Es wird allerdings damit begründet, dass man eben mehr Möglichkeiten hat und Design von Logik deutlich bessern trennen kann.
Eventuell machst du was falsch? Was hast du denn versucht was so verdammt kompliziert war?
Dravere schrieb:
CSL schrieb:
Ich arbeite seit ende 2008 mit WPF und ich habe das absolute gegenteil erlebt was du hier schilderst, und wir setzen WPF auch schon kommerziell in unseren Applikationen ein, und www.my-libaries.de
Die Seite wiederspigelt meine Erfahrung mit WPF:
"Could not locate remote server"Mal wieder n typo im link, mach ich in letzter Zeit öfter
Aber meine Seite kennst du ja bestimmt sowieso schon
-
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
-
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 ^^
-
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/257Die 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
-
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 : ObenNur 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.
-
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
-
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.
-
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 verstehenCSL 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önnenGrüssli
-
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
-
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.
-
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 mirIch 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
-
Von Hier
http://ctlabs.blogspot.com/2010/04/visual-studio-2010-net-40-and-winforms.htmlVia:
http://blogs.msdn.com/somasegar/archive/2008/11/12/net-fx-4.aspxOps ist ein Kommentar von Matt Gibbs, Development Manager – UI Framework and Services – Microsoft
-
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?
-
[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 mirUps, 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