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.
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!
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...
Eine eigene Frage?
Dieser Thread ist über 3 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
