Microsoft Visual Studio und Forms in C++

[B. P. (skorpionx)]

Kann man mit Microsoft Visual Studio ohne Umständen auch mit
Forms(ähnlich wie Borland C++ Builder)in C++ Programmieren?
Ich möchte die letzte Version  von  visual studio
community 2022 verwenden.

[Jan K. (jan_k)]

Es gibt auch für C# Winforms, ja.

[C-hater (c-hater)]

B. P. schrieb:
> Kann man mit Microsoft Visual Studio ohne Umständen auch mit
> Forms(ähnlich wie Borland C++ Builder)in C++ Programmieren?
> Ich möchte die letzte Version  von  visual studio
> community 2022 verwenden.

Ja, es gibt sogar mindestens zwei Varianten dafür, WindowsForms und WPF. 
Trotz der zwischenzeitlich doch schon jahrzehntelangen Existenz von WPF 
sind die Windows-Forms bezüglich des Komforts zur Entwurfszeit immer 
noch absolut unerreicht und es ist bei WPF auch seit langem 
diesbezüglich keine nennenswerte Verbesserung mehr erkennbar.

Leider haben die Window-Forms aber auch massive Nachteile. Insbesondere 
kommen sie mit der Kombination aus wirklich hohen Display-Auflösungen 
und physisch kleinen Displays gar nicht gut klar. Sprich: insbesondere 
mit modernen Mobilgeräten. Aber auch schon ein 27"-4k-Monitor kann sie 
deutlich über die Grenze der praktischen Benutzbarkeit treiben.

[Harald K. (kirnbichler)]

Echtes C++ ist das nicht, sondern es nutzt den .Net-Unterbau.

[C-hater (c-hater)]

Harald K. schrieb:
> Echtes C++ ist das nicht, sondern es nutzt den .Net-Unterbau.

Nein. Beides (sowohl WindowsForms als auch WPF) wird auf dem API-Level 
in C++ abgehandelt (WindowsForms sogar in den grundlegenden Teilen in 
pure C, man kann damit Anwendungen programmieren, die tatsächlich noch 
vollständig ohne diesen ganzen C++-Müll auskommen).

[Harald K. (kirnbichler)]

Bitte was? Du willst WindowsForms in reinem C nutzen können?

> Windows Forms ist ein GUI-Toolkit im .Net-Framework und im .NET.
> Es ermöglicht die Erstellung grafischer Benutzeroberflächen (GUIs)
> für Windows. Dies geschieht im Wesentlichen durch das Wrappen
> der existierenden Windows API in Managed Code.

(https://de.wikipedia.org/wiki/Windows_Forms)

[C-hater (c-hater)]

Harald K. schrieb:

> Bitte was? Du willst WindowsForms in reinem C nutzen können?

Indem man das C-API halt ohne "Windows.Forms" benutzt. Ja, ist ein 
"klein wenig" weniger komfortabel, aber geht.

Wenn man's etwas komfortabler haben will, geht auch noch MFC. Das ist 
dann allerdings schon wieder C++.

>> Dies geschieht im Wesentlichen durch das Wrappen
>> der existierenden Windows API in Managed Code.

Ganz genau. Nun laß' dir einfach noch die Implikationen dieser Aussage 
durch den Kopf gehen...

[Harald K. (kirnbichler)]

C-hater schrieb:
> Indem man das C-API halt ohne "Windows.Forms" benutzt. Ja, ist ein
> "klein wenig" weniger komfortabel, aber geht.

Das ist etwas komplett anderes.

Natürlich kann man die Win32-API aus nativem C heraus nutzen -- die ist 
dafür da, und so hat man halt in der ersten Hälfte der 90er seine 
Windows-Programme geschrieben. War ja auch keine große Umstellung zur 
Art der Windows-Programmierung unter 16-Bit-Windows.

Was Du aber hier geschrieben hast, strotzt vor kompletter 
Ahnungslosigkeit:

C-hater schrieb:
> Beides (sowohl WindowsForms als auch WPF) wird auf dem API-Level
> in C++ abgehandelt (WindowsForms sogar in den grundlegenden Teilen in
> pure C, man kann damit Anwendungen programmieren, die tatsächlich noch
> vollständig ohne diesen ganzen C++-Müll auskommen).


Oder willst Du darauf hinaus, daß letztlich jede 
Windows-Gui-Programmierung "untenrum" auf der Win32-API landet? Welch' 
große Erkenntnis. Wahnsinnn.

[B. P. (skorpionx)]

Super!:
https://www.rkaiser.de/c-winforms-anleitung/

[B. P. (skorpionx)]

Vor Jahre habe ich ein Projekt in Visual c++ 2010 in Forms
erstellt. Das ging  sehr mühsam. Ich programmierte  nur in
c++. Visual c++ 2010 war nicht dazu ganz bereit. Es kammen
viele Fehler. Jetzt habe die neueste Version 2022 installiert
nach dem „Rezept“ vom RKaiser.
Mein altes Projekt habe ich geladen und neu erstellt. Visual
Studio hat den Unterschied zwischen 2010 und 2022 bemerkt.
Nach der Frage nach dem Update habe ich positiv reagiert.
Danach wurde das Projekt fehlerfrei erstellt. Meine Sehnsucht
nach dem Borland c++ Builder ist kleiner geworden...

[Harald K. (kirnbichler)]

B. P. schrieb:
> Ich programmierte  nur in c++.

Nein, tatsächlich hast Du das nicht getan, sondern in einer 
Microsoft-Abart namens "Managed C++". Denn Du nutzt den .Net-Unterbau, 
und der ist mit echtem C++ ebensowenig verwendbar wie mit echtem C.

[B. P. (skorpionx)]

Harald K. schrieb:
> Nein, tatsächlich hast Du das nicht getan, sondern in einer
> Microsoft-Abart namens "Managed C++".

Zitaten von Wikipedia:
C++/CLI ist eine von Microsoft entwickelte Variante der
Programmiersprache C++...
C++/CLI ist das Ergebnis einer grundlegenden Überarbeitung von
Managed C++, der ersten Version von C++ mit Spracherweiterungen
für die .NET-Plattform.

Für jemanden der C++ Programmiert kann  ist  Microsoft Visual
Studio und Forms in C++ eine gute Möglichkeit die bekannte
Computersprache (vielleicht manchmal mit Problemen die zu
beseitigen sind…) weiter zu verwenden. Keine Lizenz und
Entwicklung Möglichkeiten ohne Grenzen...

[Harald K. (kirnbichler)]

B. P. schrieb:
> Zitaten von Wikipedia:
> C++/CLI ist eine von Microsoft entwickelte Variante der
> Programmiersprache C++...

Eben. Das ist kein C++, das wird nur von MS so genannt. (Früher hieß das 
"Managed C++", jetzt wird es "C++/CLI" genannt, das Konzept aber ist 
dasselbe).

Wer sich in die Abhängigkeit vom .Net-Unterbau begeben will, der braucht 
das.

[B. P. (skorpionx)]

Noch von Wikipedia:
C++/CLI ist das Ergebnis einer grundlegenden Überarbeitung von Managed 
C++, der ersten Version von C++ mit Spracherweiterungen für die 
.NET-Plattform. Managed C++ litt unter Akzeptanzproblemen, weil viele 
Programmierer die Syntaxerweiterungen als schwer lesbar empfanden.

[Harald K. (kirnbichler)]

Ja, aber das ändert nichts daran. Das ist und bleibt kein C++, sondern 
ein ausschließlich für den .Net-Unterbau verwendbarer "Dialekt". Auch 
wenn das jetzt lesbarer geworden ist.

[B. P. (skorpionx)]

Das wichtigste ist, dass c++ Syntax  behalten ist. Zugriffe
auf Hardware sind in vielen Fällen anders aber wenn man die
in einem Programm beherrscht dann ist die Sache gelernt für
alle Folgende Projekte.

[Udo K. (udok)]

Harald K. schrieb:
> Ja, aber das ändert nichts daran. Das ist und bleibt kein C++, sondern
> ein ausschließlich für den .Net-Unterbau verwendbarer "Dialekt". Auch
> wenn das jetzt lesbarer geworden ist.

Du kannst da neben dem .Net Unterbau auch auf native C und C++ Libs 
zugreifen, zumindest mit C++/CLI.

[C-hater (c-hater)]

Udo K. schrieb:

> Du kannst da neben dem .Net Unterbau auch auf native C und C++ Libs
> zugreifen, zumindest mit C++/CLI.

Das ist eigentlich der entscheidende Punkt: Du kannst all die 
Annehmlichkeiten und den umfassenden Komfort des .Net-Framework 
benutzen, mußt aber nicht auf die Benutzung von nativen C/C++-Codeteilen 
verzichten.