Laden...

Vorteile von WPF?

Erstellt von t-master vor 16 Jahren Letzter Beitrag vor 15 Jahren 16.618 Views
T
t-master Themenstarter:in
179 Beiträge seit 2007
vor 16 Jahren
Vorteile von WPF?

Hi

ich versteh immernoch nicht ganz die Vorteile von WPF gegenüber WinForms.
WPF-Programme werden ja mit DirectX gerendet, die GUI sollte als flüssiger laufen, oder?
Und was ist mit WinForms-Controls, die ich per WindowsFormsHost einfüge?
Werden die dann auch in DirectX gerendert? Gibts da irgendwelche Einschränkungen?

t-master

V
86 Beiträge seit 2008
vor 16 Jahren

Ein großer Vorteil ist die Trennung von Code und Design, weiterer auch die Vektorgrafiken, die sehen daher nicht irgendwann verpixelt aus, zum Beispiel Buttons.
Ansonsten, Performance Tests hab ich noch nicht gemacht.
Kleiner Nachteil ist OpenFileDialog michImMomentAufreg, der sieht aus wie bei Windows 2000...

M
29 Beiträge seit 2006
vor 16 Jahren

Bin auch neu was WPF angeht - daher nur halbwissen.
Ich versuch aber trotzdem mal Punkte zu nennen die ich als Vorteile sehe:
Durch die einführung von XAML als Beschreibungssprache für das GUI ist Code und Oberfläche sauberer getrennt. Ein Designer arbeitet also am XAML-Code, erstellt Templates für die Controls und muss sich nicht um die Programmierung kümmern. Der Entwickler dagegen kann die vorgegeben Funktionen implementieren. Die genaue beschaffung des GUI interessiert dabei nicht.
Außerdem kann so zimlich jedes Steuerelement jeden erdenklichen Inhalt darstellen. Eine ListBox kann dann z. B. Bilder oder gar Videos enthalten, und das wie selbstverständlich. Mit den WinForms ist das ja nicht ganz trivial.

Der weitere Punkt ist (wie du selber erwähnt hast) DirectX. Das ausschlaggebene ist dabei aber wie ich finde weniger die Leistung (natürlich auch - aber sauber Programmiert läuft eine WinForms Anwenund ja auch flüssig auf normalen PCs) sondern die Möglichkeit, auch auf DirectX-Effekte (echte Transparenz, Schatten, etc) zugreifen zu können sowie 3D-Aufgaben gleich mit der GraKa zu bewälltigen.

Dann noch das Databinding (was ich leider noch nicht ganz verstanden habe, aber ich arbeite daran). Du kannst über das XAML z. B. einer ListBox eine Collection als Quelle zuweisen und automatisch sind die beiden Syncronisiert ohne dass du selber Code schreiben muss, um das zu überwachen.

Das ist das was ich nach meinen Recherchen bis jetzt so erkannt habe.
Falls irgendwas grundlegend falsch sein sollte bitte ich natürlich um Aufklärung 😁

EDIT: Da war wohl jemand schneller...

"Keep On Rockin' In The Free World!" Neil Young

6.862 Beiträge seit 2003
vor 16 Jahren

Hallo,

ohne großartig zu erläutern will ich auch mal nen paar Features nennen die WPF auszeichnen:*webähnliches Layoutsystem welches viel flexiblere Layouts ermöglicht als Windows Forms *Endlich weg von dem beschränkten Clipping basierten GDI+ Painting *Rich Text Model - endlich kann man alle möglichen Arten von Text ordentlich darstellen *Styles/Templates/DataBinding - einfach göttlich 😉

*Integrierte Unterstützung von Audio und Video *Navigationssupport ähnlich wie bei Webseiten.

Die vielen neuen Features setzen die Lernschwelle recht hoch, aber wenn man einmal drüber ist, verstanden hat wie Templates, Styles, DataBinding, Content Models etc. ineinander greifen, dann ist man schier begeistert von den Möglichkeiten.

Baka wa shinanakya naoranai.

Mein XING Profil.

S
489 Beiträge seit 2007
vor 16 Jahren

In meiner Firma setzen wir ebenfalls WPF ein, habe aber dazu noch Kritikpunkte anzugeben:

Es fehlen einfach noch standartisierte Komponenten, so gibt es von MS noch kein DataGridView und die zur Zeit existierenden Designer können WPF und WinForms nicht mischen (das muss zur Laufzeit passieren).

Klar, es gibt viele proprietäre Komponenten von anderen Firmen für WPF (so auch einige DataGridViews), aber die muss man sich entweder dazu kaufen oder selber entwickeln und meist sind sie (noch) nicht so leistungsfähig wie die WinForms-Komponenten.

Das Resultet ist, dass ich WPF und WinForms mische (-n muss). So gehen mir damit schon einige Vorteile flöten. Nutze ich heute eine proprietäre Komponente (z.B. ein WPF-DataGridView) muss ich damit rechnen, dass ich bei der nächsten .NET Version diese Komponente wieder rauswerfen muss, weil MS so eine Komponenten dann vielleicht mitliefert und ich lieber bei Standards bleibe.

Aber ganz klar, WPF ist eine gute Technologie.

T
t-master Themenstarter:in
179 Beiträge seit 2007
vor 16 Jahren

ja, wenn ich das mache, werd ich auch viel mischen müssen (so 75% der Gui meines Progs sind WinForm-Spezifische Komponenten),
aber ich denke ich werd mich zumindest mal in WPF einarbeiten
und ein weiterer Vorteil für mich sehe ich darin, dass ich das ganze zum Portieren umstrukturieren muss und ich so mal wieder n bisschen aufräume kann ^^

Eine Frage hätt ich noch:
Mein Programm nutzt wie schon beschrieben recht viele WinForms-Controls, gibts da allzu große Nachteile, wenn ich da viel mit dem WindowsFormsHost arbeite?

925 Beiträge seit 2004
vor 16 Jahren

Frage dazu: warum benutzt ihr WindowsForms Komponenten? Und welche?

T
56 Beiträge seit 2006
vor 15 Jahren

Ich bin gerade dabei ein eigenes Steuerelement für eine Chart Darstellung zu schreiben. Dabei ist mir eins klar geworden, die Flexibilität, die WPF Steuerelemente bieten, geht einher mit einer erhöhten Komplexität bei der Steuerelement Entwicklung.

Obwohl ich zwei Bücher und die komplette MSDN Doku zu WPF gelesen habe, komme ich bei der Entwicklung in arge Nöte.

In der MSDN Doku stehen oft nur ganz allgemeine Beschreibungen; wie z.B. das Rendern funktioniert (Stichwort: CompositionTree in Milcore) oder das ContentElemente doch bitte in einem Visual gehostet werden sollen. Wie genau das aussehn soll, darüber schweigt sich die MSDN aus, auch ein Beispiel sucht man vergeblich.

Ich habe mir den Quellcode zu WPF angesehn und muss sagen, daraus wird man auch nicht viel schlauer. Da bräuchte man noch jede Menge andere Infos, wie ist das Konzept dahinter, welcher Abhängigkeiten gibt es etc. (Einige UML Diagramme dazu und Beschreibungen wären cool). Ohne dies ist es fast unmöglich die Funktionsweise wirklich nachzuvollziehen.

Man liest ja oft, dass es in WPF immer verschiedene Wege gibt das selbe zu machen. Das wird auch bei 2D Zeichungen so gesagt, es gibt Drawing, Visuals und Shapes. Im Prinzip hat man 3 mal die selbe Basis Funktionalität, z.b. das Zeichnen einer Ellipse. Der Unterschied liegt hier im Rest, also Shape kann z.B. im Gegensatz zu den anderen direkt in eine Oberfläche eingefügt werden. Wieso gibt es nicht einfach eine einzige 2D Zeichen Klasse und diverse Dekoratoren, z.b. ein UIElementDekorator. Wenn man eine 2D Zeichenklasse mit einem UiElementDekorator dekoriert, dann kann man das direkt in in die Oberfläche einfügen. Das müsste meiner Meinung nach nichtmal explizit geschehn durch den Nutzer sondern könnte automatisch implizit geschehen. Immer wenn man direkt eine 2D Zeichnung einfügt in XAML wird im Hintergrund zuätzlich noch ein UIElementDekorator in den VisualTree gehängt.

Die Performance ist auch total schwierig zu bewerten. Es handelt sich ja um ein Speichergrafik System. Aber wie ist das, wenn ich ein PolylineSegment habe und nun ändert sich einer von 100 Punkten, werden dann alle Linien, die die Polyline ausmachen neu gezeichnet oder nur die betroffenen Linienstücke? Denke das hängt davon ab, ob die Polyline im Composition Tree in einzelne Linen "angehängt" wird.
Gut andererseits ist das wohl auch ein Vorteil der deklarativen Erklärung einer Oberfläche. Man sagt nur was man haben will, aber nicht wie. So kann man WPF tunen in Zukunft ohne Angst, dass alte Anwendungen plötzlich nicht mehr laufen. Aber wie gesagt, ist es ohne Kenntnis des genauen wie's fast unmöglich die Performance zu verbessern. Gut, in so Fällen ist man sicher mit DirektX besser beraten.

Aber warum interessiert mich das? Naja mein Chart soll mehrere Funktionen gleichzeitig darstellen können. Wenn sich nur eine von drei Funktionen in der Kollektion ändert, dann sollte idealerweise nur diese neugezeichnet werden. Wenn ich die drei Funktionen in OnRender zeichne, dann nehme ich mal an, dass alle immer neugezeichnet werden. Gesondert gezeichnet werden also immer nur einzelne Visuals im Tree, vermute ich einfach mal. Wer enthält eigentlich Zeichen Informationen im VisualTree, alle Knoten oder nur die Blätter? Also muss ich dann jede Funktion einzeln in den Visual Tree hängen, damit im obigen Fall wirklich nur die sich geänderte Funktion neugezeichnet wird. Diese wird dann mit den schon gezeichneten unveränderten Funktionen zusammengesetzt, nehm ich an.

Also sollte man in OnRender nur Sachen zusammen zeichnen, die sich auch immer zusammen ändern? Das ist mal meine Theorie, da ich die genauer Funktionsweise von WPf nicht kenne, kann ich das nicht genau sagen, ärgerlich.

S
489 Beiträge seit 2007
vor 15 Jahren

Frage dazu: warum benutzt ihr WindowsForms Komponenten? Und welche?

DataGridViews, da gibt's nix von Microsoft und auf dem freien Markt gibt's dazu nur Schrott.

Richtig, für WPF gibt's nur sehr wenig Doku, auch die MSDN ist hier noch im Aufbau und die zur Zeit erhältlichen Bücher bringen einen auch nicht weiter. Da heisst es selber machen oder Kompromisse eingehen oder eben auf bessere Dokumentationen warten. 🙂

T
t-master Themenstarter:in
179 Beiträge seit 2007
vor 15 Jahren

zum Beispiel
oder Eben ne gescheite TreeList, die Inplace Editoren oder Fortschrittsbalken in den Zellen erlaubt

N
4.644 Beiträge seit 2004
vor 15 Jahren

DataGridViews, da gibt's nix von Microsoft und auf dem freien Markt gibt's dazu nur Schrott.

Hab es nicht weiter angesehen, aber hier ist die Express Version wohl kostenlos.

S
489 Beiträge seit 2007
vor 15 Jahren

Kennen wir bereits, ist Schrott. Es geht uns auch nicht um's kostenlos.

M
233 Beiträge seit 2006
vor 15 Jahren

Warum ist das Xceed-Grid Schrott ?

1.433 Beiträge seit 2006
vor 15 Jahren

Vorteil von WPF ist natürlich aus, dass eine WPF Anwendung die auf einem Client installiert werden kann, die Darstellung für die weitere Verwendung (wenn notwendig) in eine Silverlight 2.0 Anwendung verwenden, ohne dass Design nochmals erledigen zu müssen.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

T
56 Beiträge seit 2006
vor 15 Jahren

Also ich will WPF nicht verteufeln, ist der richtige Weg, aber da ist denke ich noch einiges zu tun.. Ich habe mir mal Essential Windows Presentation Foundation von Chris Anderson bestellt, das soll vom Niveau nochmal über WPF Unleashed liegen. Aber ist auch klar, immerhin ist das von langjährigen WPF Entwickler bei Microsoft. Ich hoffe da einige Antworten zu finden, wo die bisherigen Bücher mir nicht weiterhelfen konnten.

Eine Frage geht schon fast in die Richtung Best Practise: Wie teilt ein Objekt, dass in einem anderen Objekt enthalten ist in WPF am besten Änderungen in seinen Eigenschaften mit? Zumal wenn das enthaltene Objekt selbst per Datenbindung an nem anderen Objekt lauscht? Eine Idee war, einfach das übergeordnete Element per Databinding an das untergeordnete zu "hängen". Aber das scheint mir ineffizient, denn bei einer Änderung in der Quelle des untergeordneten Element wird erst dieses benachrichtigt und dann nochmal das dadrüber. Eine Lösung wäre, dass das übergeordnete Element eine Bindung an die Quelle des untergeordneten Elements vornimmt und das sich gleichzeitig das untergeordnete Element "abbindet". Damit wird dann immer direkt das übergeordnete Element benachrichtigt direkt ohne Overhead. Man muss dann nur noch bei Änderungen des Untergeordneten Elements die Bindung oberhalb eventuell neu herstellen. Aber ist dass eine zusammenschusterte Lösung von mir oder ist das ein guter Weg das obige Problem zu lösen? Ich weiss es nicht!

.
332 Beiträge seit 2006
vor 15 Jahren

Ich finde WPF auch sehr interessant.

Das Prinzip, Controls in Controls nun wirklich zu verschachteln war unter Windows.Forms immer sehr schlecht möglich.

Endlich gibt es verschiedene Layout Manager. Dieser Punkt war unter Java bisher ein riesen Vorteil.

Das schlimmste ist aber, dass die Doku nicht wirklich komplett ist. Ich habe einpaar Problem, dazu existiert auch ein Thread: ListView und WrapPanel

Diese Probleme konnte ich noch immer nicht lösen. Ich frage mich, wieso die Doku und sonstige Artikel oder Bücher darauf keine Antwort geben können.

Vielleicht ist meine Denkweise noch eine andere. Für mich ist aber genau dieser Faktor ausschlaggebend.

Mir fehlt da leider etwas der Überblick.

354 Beiträge seit 2004
vor 15 Jahren

Vergesst nicht, WPF ist noch nicht so alt. Es ist klar, dass es jede Menge Dokumentation zu Themen gibt, die bereits 10 Jahre oder mehr hinter sich haben.

Mit der WPF wurde 2003 begonnen und 2007 veröffentlicht. Da kann natürlich noch nicht soviel Material zu bestehen. Zusätzlich haben sich natürlich grundlegende Konzepte geändert (immerhin wird hier einiges zusammen geführt, WEB, GDI+, Windows Forms, DirectX, etc.). Das ergibt natürlich einen gewaltigen Unterschied zur (beispielsweise) Windows Forms Entwicklung. Einige Dinge funktionieren einfach anders, als man es bisher gewohnt war.

Dies sehe ich nicht unbedingt als Problem an. Es ist lediglich eine Gewohnheitssache, die sich einschleicht, wenn man einige Zeit damit gearbeitet hat.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

.
332 Beiträge seit 2006
vor 15 Jahren

Ich sehe es schon als Problem.

Dadurch ist es erst garnicht möglich etwas bestimmtes zu entwickeln. Wenn dies spezielle Sachen wären, würde ich es genauso sehen. Teilweise handelt es sich dabei aber um Grundlagen.

354 Beiträge seit 2004
vor 15 Jahren

Was kann dadurch beispielsweise nicht entwickelt werden?

Die Konzepte wurden geändert und angepasst, damit eben viele Dinge wesentlich besser und effizienter entwickelt werden können. Ohne diese Änderungen hätte etwas wie die WPF das Licht der Welt erst gar nie erblickt.

Ausserdem ist es fatal zu sagen, dass etwas nicht gemacht werden kann, nur weil sich eben etwas daran geändert hat, wie ich es bisher machte.

Alleine das Eventsystem: Direct Events wie sie beispielsweise in den Windows Forms gehandhabt werden decken einfach nicht sämtliche Möglichkeiten ab. Daher wurden Bubbling und Tunneling Events eingeführt. Nichts desto trotz können Direct Events immer noch verwendet werden. Dies entspricht nun keiner kompletten Änderung, sondern eine Erweiterung des bisherigen Konzeptes und somit auch eine Erweiterung der bisherigen Möglichkeiten. Das ist doch gut so.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

.
332 Beiträge seit 2006
vor 15 Jahren

Es ist nicht möglich etwas bestimmtes zu machen. Weil nirgendwo zu finden ist, wie es geht 😉

Ich will keinesfalls behaupten, dass es nicht möglich ist, weil der Umfang fehlt.

354 Beiträge seit 2004
vor 15 Jahren

Ok, du hast es auf das Thema Dokumentation bezogen.

Nun gut, auch hier gibt es entsprechende Ressourcen. Sicherlich wird noch nicht alles was möglich ist abgedeckt, aber was ist auch ein schier unmögliches Unterfangen. Die grundsätzliche Dokumentation der MSDN ist nicht schlecht, auch werden alle Konzepte erklärt, inklusive sämtlichen Klassen, wo ebenfalls Beispiele vorkommen.

Dann gibt es natürlich viele Blogs mit zahlreichen Beiträgen wie bestimmte Probleme gelöst werden können, als auch diverse Communities, die sich mit diesem Thema beschäftigen.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

.
332 Beiträge seit 2006
vor 15 Jahren

Ich sitze seit einem Monat an paar Sachen die für mich Grundlagen sind und habe noch nichts gefunden, dass mir bei der Lösung helfen könnte.
Wenn du Lust und Zeit hast, wäre es super, wenn du einen Blick auf folgende Thread werfen könntest:
ListView und WrapPanel

Vielleicht verstehe ich auch etwas falsch und es ist einfacher als ich dachte. Aber ich frage mich halt, wieso etwas so Grundlegendes, nirgendwo angesprochen wird.

C
182 Beiträge seit 2006
vor 15 Jahren

Warum ist das Xceed-Grid Schrott ?

Würde mich auch interessieren!

-christoph

F
10.010 Beiträge seit 2004
vor 15 Jahren

Mich auch.

Und wem das nicht gefällt, kann sich das kostenlose Grid von Infragistics anschauen.

Und Falls es noch keiner gesehen hat, im FW3.5 SP1 ist ein Ribbon für WPF enthalten.