Forms oder WPF

  • WPF

Es gibt 33 Antworten in diesem Thema. Der letzte Beitrag () ist von UlliS.

    Guten Morgen :)

    ich habe auch schon etwas mit WPF gespielt, aber wenn man aus der Windows Forms Welt kommt, ist das ganze mit WPF etwas holprig und nicht so durchsichtig (auch nicht mit dem Code Behind).
    Auch der Unterschied zwischen Studio 10 und der aktuellen Version ist beim WPF Designer extrem finde ich.

    Beispiel: Wenn ich in Windows Forms eine Menü oder eine Statusbar in die Form ziehe dann kann ich die ganz einfach da andocken lassen wo ich das möchte (oben, unten etc.). Das funktioniert bei WPF irgendwie nicht so einfach.
    Auch wenn die Einträge in einem Menü sehen und ändern möchte kann ich das wohl nur über den Viewer, aber nicht mit einen einfach Click in darauf wie bei Forms. Bei WPF gehts bei mir sehr träge voran :)

    Ich bin aber immer noch der Meinung, dass Ich WPF einfach falsch bediene.
    Das war ja immer das schöne an Visual Studio, dass man sich nicht so extrem um den Designercode kümmern muss und schnell ans Ziel kommt, da man sich um den eigene Code kümmert.

    Also gerade wenn man schnelle in kleines Tool bauen möchte, stellt sich der derzeitige Zeitaufwand bei WPF als Extrem dar im Gegensatz zu den Forms.

    Gibt es ein paar gute evtl. auch deutsche Tutorials zum WPF Einstieg oder was könnt Ihr empfehlen?

    UlliS schrieb:

    Gibt es ein paar gute evtl. auch deutsche Tutorials zum WPF Einstieg oder was könnt Ihr empfehlen?

    Ich arbeite gerade eines aus welches wirklich von ganz Anfang über dann MVVM und mehr geht. Immer mit diversen Zwischenschritten. dauert aber leider noch, hab gerade wenig Zeit.

    Wenn ich in Windows Forms eine Menü oder eine Statusbar in die Form ziehe dann kann ich die ganz einfach da andocken lassen

    Bruschst du in der WPF gar nicht docken. die meissten Controls füllen immer den Platz aus. Vergiss in der WPF die Werkzeugbox. Schreibe den XAML rein, es gibt ja intellisense. Auch wenn es komisch klingt. Du bist schneller wenn du Ihn tippst, weil du nicht die ganzen Margin und das alles nachträglich entfernen musst. Ich habe die Toolbox gar nicht offen.

    as war ja immer das schöne an Visual Studio, dass man sich nicht so extrem um den Designercode kümmern muss und schnell ans Ziel kommt

    Dafür hatte es andere Tücken, wo du dann den Designer code korrigieren musstest.

    Gerne helfen wir die wenn du im WPF bereich fragen stellst.
    Das schaffst du schon. :thumbup:

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Nofear23m schrieb:

    WinForm : Windows Desktop.

    Kann ich auch:
    WPF: Windows stuff
    WinForm: Linux/FreeBSD/Mac/Windows

    Und noch weiter
    WPF: .Net sprachen(C#/VB.Net - vlt. auch J# und F#?)
    Klassisch(im Prinzip dasselbe wie WinForm, WinForm ist halt eben nur der Wrapper): C/C++/Pascal/Pearl/Delphi/Assembler/Python/Rust/Ruby... ich denke du siehst was ich sagen will?

    Nun welche der beiden Technologien hat denn nun eine Zukunft und welche nicht?
    Richtig, am ehesten die klassische Variante über WinAPI, welche dann halt verändert wird und irgendwann gleich/ähnlich wie WPF aufgebaut werden kann. (Klar man könnte es auch so sehen, dass das ja dann was völlig neues ist.)

    Abgesehen davon hab ich zwar mit WPF noch nicht viel gemacht, aber es hat mir immer Kopfschmerzen bereitet und hab dann irgendwelchen roundabout scheiß programmiert nur um DataBinding verwenden zu können. Und wie es scheint hat noch nie jemand probiert DependencyProperties über mehrere ebenen weiterzuleiten :D
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Ja genau das wäre auch so was "DependencyProperties" sowas ähnliches habe ich in meinen nächsten Projekt vor und bereits in Forms am laufen.
    Ich benutze eigene Controls aufgebaut auf Forms als Bausteine und vererbe diese weiter, genuzt in einer MDI Anwendung (ne Art GUI Designer).

    jvbsl schrieb:

    irgendwelchen roundabout scheiß programmiert nur um DataBinding verwenden zu können

    Wenn du eine korrekte(!!) ViewModel Klasse hast brauchst du nix weiter und auch keinen "Roundabout"

    jvbsl schrieb:

    nie jemand probiert DependencyProperties über mehrere ebenen weiterzuleiten

    Doch
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    C#-Quellcode

    1. class X
    2. {
    3. int bla{get;set;}//Dependencyproperty stuff
    4. }
    5. class Y
    6. {
    7. X X{get;set;}//Dependencyproperty stuff
    8. int bla => X.bla;
    9. }

    Und ja, dafür hab ich einen roundabout gebraucht, denn databinding bekommt nicht mit, wenn sich Y.bla ändert, da er dafür X.bla quasi ändern müsste. Mach mir mal das ohne Redundanz(Und ohne INotifyPropertyhanged).
    Mir ist klar, dass es vermutlich eine halbwegs sinnvolle Lösung gibt, aber manchmal macht WPF einem das leben halt schwerer als es ist.
    Und die anderen Argumente stehen immer noch :P
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    jvbsl schrieb:

    Nun welche der beiden Technologien hat denn nun eine Zukunft und welche nicht?


    Auf lange Sicht vermutlich keins der beiden. Eher Xamarin Forms und UWP. Dieser Artikel (A WPF Q&A) ist zwar schon älter aber: Microsoft is not planning on any investing in major changes to WPF und auch Windows Forms is continuing to be supported, but in maintenance mode. They will fix bugs as they are discovered, but new functionality is off the table.



    PS: @jvbsl, Wenn ich mir deine Artikel jetzt durchlese muss ich immer Lachen, weil ich mir vorstelle wie du sie laut vorliest :D

    Bluespide schrieb:

    Eher Xamarin Forms und UWP
    Mit Xamarin.Forms 3.0 wird WPF ordentlich degradiert, da dann Xamarin.Forms mit (hoffentlich) XAML Standard die UI übernehmen wird, um Cross-Plattform UI zu schreiben. WPF ist dann "nur noch" die plattformspezifische ausführende Einheit. Natürlich kann man es weiterhin für reine Windows Apps benutzen, da jedoch inzwischen alles App ist, (selbst Konsolenanwendungen :D), schätze ich, wird WPF auch irgendwann nur noch in "maintenance mode" gefahren werden.
    Post-AGB:
    §1 Mit dem Lesen dieses Posts stimmst du den AGB unverzüglich zu
    §2 Ein Widerruf muss innerhalb von 3 Sekunden nach Lesen des Hauptbestandteil des ersten jemals gelesenen Posts erfolgen
    Abs.1 Die Signatur zählt nicht zum Hauptbestandteil des Posts
    §3 Ein erfolgreicher Widerruf zwingt zu einem Besuch bei einem Hypnotiseur oder Neurochirurg, sodass der gelesene Text aus den Erinnerungen entfernt werden kann
    Abs.1 Die Kosten und Risiken sind jeweils selbst zu tragen
    tja, prinzipiell machste mich neugierig auf Xamarin.
    Habichdoch gleich im Tutorial-Bereich geguckt, aber da gibts nur ein tut, das beschäftigt sich mit Installations-Problemen, und mit Xamarin, und Android SDK muss man auch runterladen, und lauter Krams von dem ich eiglich nix wissen will.
    Bist du dir sicher, dass Xamarin demnächst Wpf in der Desktop-Entwicklung ablösen wird?
    Weil auf das Gehampel bin ich eiglich nicht soo scharf, und bei Wpf findich schnucklig, dasses im Framework mit OnBord ist (was bei Xamarin nicht der Fall ist, oder?).


    Oder ist etwa Xamarin vlt. nicht auch nur sone Eintagsfliege, wie es etwa Linq2Sql war?
    Erst ganz was dolles und Super-Hype, und dann kommense mit EF hinterher, und Linq2Sql ist so tot wie die ArrayList (falls sich noch einer an die erinnert).

    ErfinderDesRades schrieb:

    Bist du dir sicher, dass Xamarin demnächst Wpf in der Desktop-Entwicklung ablösen wird?
    Die reine Windows Desktop-Entwicklung vielleicht nicht, doch sobald du auf andere Plattformen schielst, ist Xamarin die Lösung wenn du C# schreiben möchtest.

    ErfinderDesRades schrieb:

    bei Wpf findich schnucklig, dasses im Framework mit OnBord ist (was bei Xamarin nicht der Fall ist, oder?).
    Nein, du brauchst zusätzliche dlls. Da es aber Xamarin Templates gibt, und entsprechende NuGet Pakete, ist das weiter kein Problem.

    ErfinderDesRades schrieb:

    Weil auf das Gehampel bin ich eiglich nicht soo scharf
    Glaub mir, das gehampel ist schon bei weitem nicht mehr so schlimm wie früher. Mit dem Installer von VS 17 ist die installation von Xamarin lediglich ein Haken (und 20GB für das Android SDK :rolleyes: ), den du anklicken musst. Der Rest wird vom Installer erledigt.

    ErfinderDesRades schrieb:

    Oder ist etwa Xamarin vlt. nicht auch nur sone Eintagsfliege, wie es etwa Linq2Sql war?
    Nachdem Microsoft die Firma gekauft hat, und das Produkt kostenlos gemacht hat, und Xamarin deren einziges mobiles Entwicklungsstandbein in ihrer Cross-Plattform und Open-Source offensive ist, ist meine Einschätzung, dass wir noch sehr lange was von Xamarin haben werden. Immerhin ist ja Microsofts aktueller Kurs Mobile first, Cloud first.

    Edit: Um etwas zum Topic beizutragen:
    Basierend auf den bisherigen Entwicklungen, ist es lohnenswert sich WPF, vor allem aber XAML anzueignen, da Microsoft nicht vorhat sich davon zu verabschieden.
    Post-AGB:
    §1 Mit dem Lesen dieses Posts stimmst du den AGB unverzüglich zu
    §2 Ein Widerruf muss innerhalb von 3 Sekunden nach Lesen des Hauptbestandteil des ersten jemals gelesenen Posts erfolgen
    Abs.1 Die Signatur zählt nicht zum Hauptbestandteil des Posts
    §3 Ein erfolgreicher Widerruf zwingt zu einem Besuch bei einem Hypnotiseur oder Neurochirurg, sodass der gelesene Text aus den Erinnerungen entfernt werden kann
    Abs.1 Die Kosten und Risiken sind jeweils selbst zu tragen
    @Bluespide:

    jvbsl schrieb:

    (Klar man könnte es auch so sehen, dass das ja dann was völlig neues ist.)


    Es wird ansich wohl auf etwas ohne .Net mit einem .Net Wrapper hinauslaufen. Also genau wie bei Forms etwas natives über WinAPI mit einem zusätzlichen(optionalem) .Net Wrapper. Wobei dafür die Struktur und Idee von WPF übernommen wird(oder man könnte auch sagen QML oder whatever sonst noch databinding hat und ähnliches layouting). Rein aus Sicht der Sprache wird es aber alles andere als ähnlich zu WPF und bestimmt auch nicht(ausschließlich) DirectX basiert.

    Edit:
    @Bluespide was du mit laut vorlesen meinst weiß ich nicht, weil sie etwa so ein Frage-Antwortspiel haben?
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Einen wunderschönen guten Morgen

    jvbsl schrieb:

    Und ja, dafür hab ich einen roundabout gebraucht, denn databinding bekommt nicht mit, wenn sich Y.bla ändert

    Das ist auch gut so, ich persönlich mag es sogar das ich selbst steuern kann wann das View was mitbekommt.
    Mal ganz abgesehen davon das du die mal ansehen solltest was DepependencyProperties sind. Du hast eben ganz normale Properties geschrieben. Bei DP benötigst du auch kein INotifipropertyChanged werden aber nie in ViewModel-Klassen angewandt, sondern im View, z.b. in UserControls um diesen Logik zu implementieren.
    Schau dir mal DP an: docs.microsoft.com/en-us/dotne…dency-properties-overview
    Schau dir mal die WPF an und Arbeite mal damit, jemandem zu raten lieber mit WinForms zu Arbeiten du weil du es nicht verstehst finde ich nicht korrekt. Wenn du der WPF eine Change gibst wird sie dich überraschen. :D


    jvbsl schrieb:

    Und ohne INotifyPropertyhanged

    Wozu? Ist ein Fixer Bestandteil der WPF. Ich kenne keinen Grund INotifipropertyChanged nicht zu verwenden? Du?

    jvbsl schrieb:

    manchmal macht WPF einem das leben halt schwerer als es ist

    Ich weis was du meinst, ich tat mir auch sehr schwer anfangs, irgendwie wusste ich im ersten Moment nicht wo oben und unten ist. Als ich dann dachte das ich soweit klar komme kam gleich wieder ein Dämpfer das ich nicht mehr wusste ich Männlein oder Weiblein bin weil ich merkte das ich mit MVVM besser dran bin und das nun lernen musste. Klar ist das nicht lustig, aber ist das nicht so das man als Progger immer wieder neues lernen muss weil immer wieder neue Frameworks kommen, im Moment beschäftige ich mich intensiv mit EF Core wo ich schon das dritte Buch lese. Ist eben so.

    jvbsl schrieb:

    Und die anderen Argumente stehen immer noch

    Sorry, für mich nicht. Ich gebe dir in einigen Punkten recht, keine Frage. Dennoch geht es hier ja darum dem Threadsteller zu helfen. Klar können wir philosophieren was es in 10 Jahren noch gibt und wo alles hinführt.
    Im Moment ist es nun mal so das ich mit XAML ein ziemlich großes Spektrum abdecken kann, die Punkte wie UWP und Xamarin sind schon genannt worden. Ich nehme hier dann noch ASP.Net MVC her, ok kein XAML aber MVC welches sehr dem MVVM Pattern ähnlich ist.
    Um Gottes willen, ich will ja nicht sagen das die WPF alles ist und das nichts anderes in Frage kommt, es gibt für jedes Projekt sein passendes Framework, finde allerdings das mal viel abdecken kann wenn man MVVM und XAML beherrscht.

    Wünsche euch noch einen schönen Tag und immer schön brav bleiben Leute
    Grüße Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Nur weil ich zu faul war die DP auszuschreiben, aber danke für die offensichtliche Info. Alle normalen DPs haben schließlich funktioniert.

    InotifyPropchange ist part von system.componentmodel und gibt es seit .net 2.0. Außerdem soll es angeblich mit Performance nicht so der held sein. Andererseits kommt es mir stark nach mischen von Technologien vor.

    Ich habe schon mehr als 30h in WPF gesteckt. In dieser Zeit hab ich auf 10 Prüfungen gelernt oder 5 andre Technologien gelernt, die um einiges schwerer sein sollten. Ich bin ein sehr schneller lerner. QML ist dabei einiges einfacher und schöner. Außerdem wird dieses bestimmt auch länger bestehen bleiben als WPF.

    Für meine eigenen Projekte werde ich solange es nicht Plattformunabhängig ist nicht hernehmen. Ich hab keine Lust nur dafür auf mein beschissen laufendes Win wechseln.

    Und Xamarin ist nicht WPF. XAML ist auch nur eine markup sprache.

    Ich helfe dem Threadersteller in dem ich gesagt habe, dass man sich WPF angucken kann wenn man eh nur auf Win entwickelt und meine persönlichen Erfahrungen genannt habe.

    Das EntityFramework beschissen implentiert wurde ist z.B. nicht nur meine Meinung.

    Ein großes Spektrum kann man mit allem Abdecken was Turingcomplete ist, ob es deshalb sinnvoll ist, ist eine andrre Sache.

    Wie gesagt erst wenn es auf Lnx funktioniert werd ich mir es angucken. Andere Zielgruppe nunmal. Databinding find ich auch nice, verwende es in Forms fast immer wenn es geht. Aber QML find ich nunmal einfacher und übersichtlicher.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Hey,

    also vielen Dank für die vielen Infos und eure Meinungen.
    Ich denke ich werde für weiteren Applikationen erst mal bei den Forms bleiben, da ich immer etwas im Zeitdruck bin ;)

    Wenn Ihr .Net Applikationen für anderen Betriebssysteme verwenden wollt, benutzt Ihr dann Mono, oder?
    Bis jetzt war ich nur in der Windows Welt unterwegs ;)