Wpf

[stahli]

Hat jemand Erfahrungen mit WPF gemacht?

Taugt das für komplexe Anwendungen mit viel Drag&Drop-Unterstützung (z.B. wenn ich meine Autos und Garagen auf meinem Anwesen verwalten und die Autos per D&D über die gepflegten Schotterwege von einer Garage in eine andere ziehen will, was für Johann dann einen "Umsetzauftrag" generiert)?

Das Beispiel soll nur verdeutlichen, dass man "Objekte" per D&D zueinander zuordnen können und auf auf einer Fläche (Designer) positionieren können soll. (Meine Autos setze ich natürlich weiter selbst um ;-))

[mkinzler]

WPF ist eine FireMonkey ähnliche Grafikbibliothek. Theoretisch kann man damit alles Lösen.

[stahli]

Na ja, ich meinte wie komfortabel oder aufwendig das Databinding in der Realität ist. Insbesondere wenn es darum geht, Zuordnungen und Positionen über D&D zu verändern.

Selbst habe ich mich noch nicht beschäftigt damit, aber wenn es Erfahrungen und Meinungen dazu gibt würden die mich interessieren.

[ExceptionOverflow]

Databinding: Lese dich bevor du anfängst die WPF zu benutzern erst mal (sofern nicht geschehen aber ich denke sonst hättest du nicht gefragt) in MVVM ein, wenn du den dreh raus hast ist das ganze nur noch eine Sache deines Codes und weniger wie du es noch zur Oberfläche bekommst und dort veränderst.
WPF ohne MVVM ist eine Qual, mit ist es jedoch ziemlich easytouse und du brauchst dich nur noch auf den eigentlichen Code konzentrieren, dahingehend bieten sich auch Frameworks wie das "light" oder "Caliburn.Micro" an (light ist glaube ich etwas weiter als Caliburn.Micro, als ich das zuletzt benutzt habe war es noch etwas eingeschränkt, durch die Namenskonventionen aber sehr einfach zu benutzen und auch wenn man sich mit dem MVVM kaum bis gar nicht beschäftigt hat).

Ich hoffe ich habe die Frage richtig aufgefasst (Teilweise zumindest, denn dein Anwendungsbeispiel hatte ich so bisher noch nicht in der Praxis) und konnte helfen, sollte ich weit daneben liegen einfach ignorieren ;)

[Dejan Vu]

Man muß sich davon verabschieden, wie in Delphi alles über 'rumklicken' hinzubekommen. Auch wird man life keine Previews hinbekommen. Aber dadurch, daß man -wie ExceptionOverflow schon schrieb- auf MVVM angewiesen ist, wird man das nicht mehr vermissen. Irgendwie dachte ich Jahre lang, das Klickbunti à la Delphi state-of-the art ist und nur Mormonen und andere Waldschrate noch Bindings per Hand kodieren. Stimmt aber nicht. Was man scheibar mehr an Tipparbeit hat bzw. was 'im Code' (des Viewmodels) steht (und nicht in der DFM), zahlt sich später mehrfach aus.

Grundsätzlich würde ich mit Winforms anfangen, wenn ich auf C# umsteige. Wenn man dann die TDataSets und das life-Rumdesigne nicht mehr vermisst, kann man auf WPF umsteigen. Na ja, wenn man kein Pfosten ist, kann man auch gleich auf WPF umsteigen, aber es tut schon ein wenig mehr weh. Die Lernkurve bei WPF ist anfangs flach (oder steil, jeh nachdem, wie man es sieht), denn man benötigt nicht nur MVVM-Kenntnisse, sondern muss sich auch damit anfreunden, das der XAML-Editor (und nicht der OI) die beste Art ist, seine Controls zu pimpen. Klingt blöd, ist aber so: der OI kann nicht alles darstellen, was man mit XAML machen kann.

[OlafSt]

Dann liege ich mit meinen Erkenntnissen in Sachen WPF ja voll auf der Linie. Will man mit WPF ernsthaft vorankommen, dann muß man sich wirklich umfassend vom bisherigen RAD-GUI-Design verabschieden. Man programmiert seine Oberfläche quasi wieder. Wer weiterhin seinen Button auf die Form droppen will, doppelklick und Code dahinter, bleibt besser bei WinForms.

[Stevie]

Zitat:

Zitat von OlafSt (Beitrag 1273932)

Dann liege ich mit meinen Erkenntnissen in Sachen WPF ja voll auf der Linie. Will man mit WPF ernsthaft vorankommen, dann muß man sich wirklich umfassend vom bisherigen RAD-GUI-Design verabschieden. Man programmiert seine Oberfläche quasi wieder. Wer weiterhin seinen Button auf die Form droppen will, doppelklick und Code dahinter, bleibt besser bei WinForms.

Afaik kann man auch in WPF das klassische "alles ins Code behind knüppeln" betreiben.
Sollte man natürlich tunlichst sein lassen. Aber das UI Design per Krams auffe Form verteilen ist dasselbe. Die Interaktion zwischen UI und Businesslogik läuft nur mehr entkoppelt voneinander.

[Dejan Vu]

Na nee. Du baust Dir deine Oberfläche schon im Designer zusammen. Du willst ja sehen, wie das aussieht. Nur unter dem Designer in der IDE ist der XAML-Editor, so als wenn der DFM-Quelltext in der Delphi-IDE zu sehen wäre (fände ich auch ganz prickelnd, manchmal). Und wenn Du da was reintippst, siehst Du es im Designer sofort.

Und bevor ich die Property im OI per Mausrad suche, tippe ich das doch gleich im XAML ein. Vor allen Dingen mit den netten Spezialitäten, wie 'relative Maße' usw.

[Stevie]

Zitat:

Zitat von Dejan Vu (Beitrag 1273939)

ist der XAML-Editor, so als wenn der DFM-Quelltext in der Delphi-IDE zu sehen wäre (fände ich auch ganz prickelnd, manchmal). Und wenn Du da was reintippst, siehst Du es im Designer sofort.

Hatte schonmal die Idee, solch einen Editor zu schreiben, habs dann aber aufgrund von wichtigeren Dingen und Zeitmangel erstmal verworfen :)

[Photoner]

Zitat:

Zitat von Dejan Vu (Beitrag 1273939)

... so als wenn der DFM-Quelltext in der Delphi-IDE zu sehen wäre (fände ich auch ganz prickelnd, manchmal)....

Formularansicht dann ALT-F12 :-D