Ich muss nach Jahren wieder eine GUI-Anwendung unter Windows vermutlich unter .NET entwickeln. Als ich das letzte mal überhaupt was mit .NET zu tun hatte, war Windows Forms das Mittel der Wahl, das wird immer noch unterstützt aber keine gute Idee darauf aufzubauen da es schon lange im Maintainance Mode. Ist WPF noch aktuell oder ist das mit UWP Geschichte? Dann gibts da noch WinUI 3, WinRT.... Was nimmt man denn heute für Anwendungen die auf einem PC laufen sollen die auf .NET aufbauen?
In deinem Fall würde ich weiterhin auf Windows Forms setzten. Ist am einfachsten, und man kommt am schnellsten zu Ergebnissen. Das wird auch noch viele Jahre unterstützt werden, da würde ich mir keine Sorgen machen.
WPF, MAUI oder wenns auch auf Linux laufen soll: AvaloniaUI Cheers, Roger
aktuell ist das XAML. Im Prinzip eine eigene, XML-basierte Programmiersprache zur Definition der GUI, abgekoppelt von der Programmlogik. Macht Sinn, wenn eigene Designer-Teams die GUI entwickeln sollen, die nicht notwendigerweise Programmierer sein müssen. Ist hip und klicki-bunti, wenn das Form rund sein soll und der Button ein Video abspielen muss. Ich hab den Sch... gelernt und dann mit Windows Forms weiter gemacht. Finde XAML eine Zumutung.... P.S. XAML IST DIE WPF!
:
Bearbeitet durch User
Gunnar F. schrieb: > aktuell ist das XAML. Im Prinzip eine eigene, XML-basierte > Programmiersprache zur Definition der GUI XAML ist nichts weiter als eine Beschreibung eines Objekt-Baums. Wenn eine XAML-Datei "ausgeführt" wird, dann werden die Objekte erzeugt. Wie diese Objekte aussehen, und wie sie sich verhalten, (und ob sie überhaupt eine GUI beschreiben,) hängt von der Bibliothek ab, die diese Objekte implementiert. Alle Microsoft-GUI-Frameworks seit WPF benutzen XAML, sind aber in den Details nicht kompatibel.
Microsoft hat die Entwicklung von GUI-Frameworks kräftig verkackt. Alles, was nach WPF kam, ist nicht sehr verbreitet, weil Microsoft ständig eine neue Sau durchs Dorf treibt (Silverlight, UWP, MAUI, WinUI); man hat die Wahl zwischen Frameworks, die entweder nicht mehr weiter entwickelt werden, oder die noch nicht vollständig sind. Windows Forms und WPF sind zwar alt, aber werden auch auf den neuesten .NET-Runtimes unterstützt. Sie werden wahrscheinlich länger leben als ihre Nachfolger. Microsoft betont zwar, wie portabel diese Frameworks sind, hält sich aber von Linux fern. Wenn das eine mögliche Anforderung ist, benutze AvaloniaUI. Oder vergiss .NET und benutze so etwas wie Electron. (Was Microsft in Teams verwendet, kann nicht falsch sein, oder? :)
Clemens L. schrieb: > Microsoft hat die Entwicklung von GUI-Frameworks kräftig verkackt. > Alles, was nach WPF kam, ist nicht sehr verbreitet, weil Microsoft > ständig eine neue Sau durchs Dorf treibt Ja, das ist leider so. > Windows Forms und WPF sind zwar alt, aber werden auch auf den neuesten > .NET-Runtimes unterstützt. Sie werden wahrscheinlich länger leben als > ihre Nachfolger. > > Microsoft betont zwar, wie portabel diese Frameworks sind, hält sich > aber von Linux fern. Nunja, andere haben die Arbeit geleistet. Heutzutage laufen Windows.Forms-basierte Anwendungen recht problemlos unter Linux. So lange sie halt wirklich nur das Framework verwenden und nicht zusätzlich umfangreiche Win-API-Importe. Das ist natürlich tödlich für die Portabilität.
c-hater schrieb: > Nunja, andere haben die Arbeit geleistet. Heutzutage laufen > Windows.Forms-basierte Anwendungen recht problemlos unter Linux. So > lange sie halt wirklich nur das Framework verwenden und nicht zusätzlich > umfangreiche Win-API-Importe. Das ist natürlich tödlich für die > Portabilität. Mono ist ja irgendwie tot sehe ich gerade. Geht das dann mit "dotnet" von MS, muss man dann die Windows Forms von github nachinstallieren oder läuft das out of the box?
Seit MS Xamarin übernommen hat ist das praktisch tot. Da werkelt noch ne "Community" dran rum, die bringt aber nix mehr Zustande ausser Regressionzombies wie den hier https://github.com/mono/mono/issues/18500 der mir vor ein paar Tagen wieder erschienen ist, wenn das Projekt am laufen wäre wäre das schon längst aufgefallen. Monodevelop ist auch tot, dafür gibts nicht mal ein Repo für ein aktuelles Ubuntu, 18.x war das letzte. Status archiviert auf github -> eingesargt und beerdigt. Da tut sich nix mehr seit MS da die Hand drinn hat, auf diversen Blogs wird das ähnlich gesehen. Mit sowas fängt keiner mehr ein neues Projekt an der noch ganz bei Trost ist.
Da lob ich mir noch die Microsoft Foundation Classes! Auch nach 25 Jahren noch "alive and kicking". Wenn's nicht portabel sein muss, für mich immer noch die erste Wahl.
MFCGuy schrieb: > Da lob ich mir noch die Microsoft Foundation Classes! Auch nach 25 > Jahren noch "alive and kicking". Wenn's nicht portabel sein muss, für > mich immer noch die erste Wahl. Windows.Forms gibt's auch schon seit .Net1.0 und somit seit 20 Jahren. Und läuft und läuft und läuft... Anfangs war es zwar ähnlich beschränkt wie MFC, ist aber zwischenzeitlich sehr viel komfortabler geworden, insbesondere bezüglich des Layout. Allerdings bin ich MFC-mäßig nicht so ganz auf der Höhe (C++ war und ist mir grundsätzlich ein unerträglicher Graus), möglich, dass es dort später auch Verbesserungen gegeben hat. Gibt es dort sowas wie TableLayoutPanel oder FloatLayoutPanel? Diese Sachen machen Windows.Forms erst für moderne GUIs brauchbar. Und stellen gleichzeitig den Sinn dieses ganzen XAML-Gewichses der späteren MS-Werke in Frage. Die Trennung von Design und Content hätte man mit ein wenig guten Willen natürlich auch basierend auf Windows.Forms hinbekommen können. Aber, wie so oft im Softwarebereich: Man erfindet lieber schnell mal was ganz Neues, wenn die Kompetenz für das Bestehende nicht (mehr) in hinreichendem Maße verfügbar ist...
MFCGuy schrieb: > Da lob ich mir noch die Microsoft Foundation Classes! Auch nach 25 > Jahren noch "alive and kicking". Wenn's nicht portabel sein muss, für > mich immer noch die erste Wahl. Funktionieren die inzwischen ? Selbst 2010 musste man noch drumrumprogrammieren weil Dinge falsch oder gar nicht implementiert waren, Direktzugriff auf Win32 war nötig. Dinge wie customized menu entries, irregular shaped windows, printing OLE objects.
Michael B. schrieb: > Dinge wie customized menu entries, irregular shaped windows Das geht mit Windows.Forms > printing > OLE objects. Das naturgemäß nur eingeschränkt. Es erfordert halt die korrekte "Mitarbeit" der OLE-Objekte selber. Und hat mit dem Framework natürlich erstmal rein garnichts zu tun. Das stellt nur einen DC und Bounds zur Verfügung und sagt dem Objekt, dass es sich halt innerhalb dieser Bounds auf den DC zu zeichnen hat. Mehr kann das Framework nicht tun. Alles andere macht das Objekt selber. Mit ein wenig Glück macht es das richtig...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.