4. Gibt es gute Alternativen zur MFC, oder sollte man lieber direkt bei WinAPI bleiben? Sprache: C++

Gibt es gute Alternativen zur MFC, oder sollte man lieber direkt bei WinAPI bleiben? Sprache: C++


  • Beefi schrieb:

    Wenn ich also bei C++ bleiben will, ist die WinAPI-Programmierung eine schlechte Wahl?

    Imo solltest du dir zumindest mal die Frage stellen, wieso genau du dich auf C++ beschränken willst. imo sollte jeder, der mit C++ für Windows entwickeln will zumindest WinAPI Basics drauf haben. Aber wenn es darum geht, komplexe GUI Anwendungen zu bauen, so würde ich persönlich mir überlegen, ob ich den GUI Teil nicht besser mit z.B. C# machen sollte...

    0
  • B

    Beefi schrieb:

    Ich las schon oft von Win32++...eine Art Framework (alternative zu MFC). Benutzt das jemand?

    Wenn ich denn mal alle Jubeljahre ein GUI-Programm mache, benutze ich das. Ich finde es ganz gut, weil es Header-only ist, ich den Source-Code bei Bedarf einigermaßen verstehen und ihm folgen kann, und man mM auch einiges über Möglichkeiten der GUI-Programmierung daraus lernen kann.

    0
  • B

    Hi,

    @dot:
    Mit deiner Antwort habe ich fast gerechnet 😃 Ja ich muss ehrlich sagen, dass ich für gewöhnlich .NET verwende. Zwar VB.NET, werde aber demnächst auf C# wechseln. Für mich ist es keine Frage, egal welche .NET-Sprache, für Windowsanwendungen ist das .NET Framework das Non-Plus-Ultra 😃

    Die Sache ist nur die, dass ich beruflich C++ können MUSS. Und da ich mit C++ nichts anderes kann als Konsolen-Programme zu schreiben bzw. mit C mal nen Mikrocontroller zu programmieren, komm ich immer relativ oft aus der Sprache heraus.

    Mein Ziel mit C++ ist es einfach nur, simple kleine GUI-Anwendungen schreiben zu können. Nehmen wir als Beispiel so ein Zip-Programm wie 7-Zip...sowas würde wohl das höchste der Gefühle sein (vom Widget-Aufbau).

    Was auf jeden Fall drin sein muss:
    Ich muss in Fenster zeichnen können und diese Zeichnung auch Drucken können. Dateien müssen simpel über einen File-Dialog ausgewählt werden können...dieser sollte dem Standard von Windows entsprechen.
    Das wars eigentlich auch schon...abgesehen von ein paar kleinen Standard-Dingen wie Buttons, Statusbar, usw.

    Da ich hier nur was simples, schnelles und kleines will und das Programm unbedingt nur EINE EXE sein muss (also GUI-Bib statisch linkbar, für kommerzielle Zwecke), dachte ich erst an FLTK. FLTK ist wahrscheinlich fast perfekt. Damit es Windows-mäßiger aussieht, dachte ich noch an wxWidgets, wobei ich hier nicht viel gutes lese (langsam, keine gute Doku, eher ein "Zusammengeschustertes Framework").
    Und so dachte ich, dass ich es einfach direkt mit der WinAPI probiere. Wobei ich dann noch auf Dinge wie Win32++ gestoßen bin, was sich sehr gut anhört...scheint aber nicht mehr weiterentwickelt zu werden.

    @Swordfish:

    Die WinAPI kann mit allen Sprachen benutzt werden, die mit einem Interface in C klarkommen.

    Gut, das beruhigt mich schon mal.

    Warum sollte ein C++-Entwickler GUI-Anwendungen in C schreiben?

    Ich habe keine Ahnung 🙂 Das schrieben hier welche im Forum, als ich nach diesem Thema gesucht hab.

    Es ist sozusagen der Weg zu Fuß. Für die gepolsterte Kutsche siehe FAQ.

    Ja das stimmt, ich habe nur Angst, dass ich mich zu Tote schreibe, wenn ich damit eine GUI erstellen will. Hast du vielleicht nen Link zu nem "Hello World" Beispiel, welches ich mal kompilieren kann? Damit ich grob sehe, was auf mich zukommt?

    Ja die Frameworks aus der FAQ kenne ich zum Großteil, ich bin schon froh, dass hier noch niemand auf Qt beharrt hat...denn genau sowas suche ich nicht 😃
    SmartWin++ scheint auch schon seit 2007 stillgelegt zu sein.
    Ultimate++ sieht ganz gut aus, aber irgendwie liest man überall, dass es sich um eine IDE handelt...kann das mal jemand erklären?

    @Belli:
    Wunderbar...auf eine Reaktion von dir habe ich gehofft, da ich immer von dir gelesen habe, wenn es hier um Win32++ ging 😃
    Sind solche Dinge wie ich oben schrieb, komplett hiermit möglich, ohne auf die WinAPI direkt zurückzugreifen? Also zb in eine PictureBox zeichnen und drucken, oder FileDialoge öffnen? Weißt du, ob daran noch weiterentwickelt wird, oder wurde das Projekt seit 2011 aufgegeben?

    Ich freue mich auf eure Antworten 😉

    Liebe Grüße,
    Andi

    0

  • Beefi schrieb:

    Die Sache ist nur die, dass ich beruflich C++ können MUSS. Und da ich mit C++ nichts anderes kann als Konsolen-Programme zu schreiben bzw. mit C mal nen Mikrocontroller zu programmieren, komm ich immer relativ oft aus der Sprache heraus.

    Wofür genau musst du C++ denn beruflich einsetzen?

    Beefi schrieb:

    Mein Ziel mit C++ ist es einfach nur, simple kleine GUI-Anwendungen schreiben zu können. Nehmen wir als Beispiel so ein Zip-Programm wie 7-Zip...sowas würde wohl das höchste der Gefühle sein (vom Widget-Aufbau).

    Sowas kannst du auf jeden Fall auch mit der WinAPI machen und wär vermutlich auch keine schlechte Übung.

    0
  • B

    Wofür genau musst du C++ denn beruflich einsetzen?

    Ich komm aus der Elektronik-Branche...und heutzutage steckt ja fast überall ein Minicomputer drin. Vor ca 10 Jahren war noch C und Assembler angesagt, womit wir Microcontroller programmierten (zb. PIC oder Atmel AVR)...jetzt müssen wir C++ beherrschen, weil fast überall ein kleines Linux drinsteckt.
    Also kurz gesagt benötige ich C++ für Embedded-Systeme.
    Privat für normale PC-Programmierung (Windows) war ich eigentlich immer der VB6-Typ bzw. jetzt lerne ich mich so langsam in .NET ein 🙂

    Sowas kannst du auf jeden Fall auch mit der WinAPI machen und wär vermutlich auch keine schlechte Übung.

    Ok, dazu noch eine Frage. In Visual Studio kann ich Fenster einfach zeichnen und dann in den entsprechenden Funktionen/Ereignissen meinen Code platzieren.
    Programmiere ich nur über die WinAPI, kann ich das ja mithilfe eines Resourcen-Editors machen. Wenn ich hiermit die Steuerelemente gezeichnet habe, muss ich diese dann nur noch per eingebundener API-Funktion ansprechen? Bzw ist es nur ein kleiner Mehraufwand im Vergleich zu VB6? Oder stelle ich mir das viel zu einfach vor? 🙂

    0
  • ?

    Ach volkard, wieso löschst du immer meine Posts -.-

    0
  • B

    Was stand denn im Post? 🙂

    0
  • -

    Beefi schrieb:

    Vor ca 10 Jahren war noch C und Assembler angesagt, womit wir Microcontroller programmierten (zb. PIC oder Atmel AVR)...jetzt müssen wir C++ beherrschen, weil fast überall ein kleines Linux drinsteckt.

    Versteh ich nicht...dies geht genauso mit asm oder C.

    0
  • B

    Versteh ich nicht...dies geht genauso mit asm oder C.

    Ja geht eigentlich schon, ist aber nicht mehr so gefragt bzw. nicht mehr so der aktuelle Stand. Man könnte bestimmt auch jedes Windows-Programm in Assembler schreiben, macht man aber nicht, da es sich nicht so wirklich rentiert (außer eben bei kritischen Systemdingen).
    Assembler und C ist ja nicht weg von der Fläche, aber als Elektroingenieur kommt man um C++ nicht mehr herum.

    0
  • K

    Fuer einfache GUIßProgramme benutye ich die Bibliothek fltk. Sie ist sowohl fuer Linux als auch Windows verfuegbar.

    0
  • B

    Fuer einfache GUIßProgramme benutye ich die Bibliothek fltk. Sie ist sowohl fuer Linux als auch Windows verfuegbar.

    Ja FLTK scheint echt super zu sein...das wäre eigentlich auch mein Favorit gewesen. Aber ich denke, ich bleibe jetzt echt erstmal bei der WinAPI und danach evtl "Frameworks" wie Win32++ oder Ultimate++.

    Ich fand FLTK auch erst angenehm, weil es auch unter Linux läuft, aber ich bin seit ner Weile wieder fest zu Windows zurück. Ich setze fest auf Windows und um hier die Hintergründe besser zu verstehen, wird die WinAPI wohl das beste für mich sein.

    Wenn ich nach Büchern zur WinAPI suchte, wurde oft der Klassiker von Charles Petzold empfohlen. Das Buch ist ja immerhin schon vom Jahr 2000. Ändert sich an der WinAPI denn gar nichts? Sollte ich jetzt nach fast 14 Jahren immer noch dieses Buch studieren, oder habt ihr noch andere Empfehlungen? Ein eBook als HTML oder PDF wäre auch super, falls es sowas gibt.

    0
  • M

    Beefi schrieb:

    ich bleibe jetzt echt erstmal bei der WinAPI

    Das bringt irgendwie nichts... Ich glaube wirklich nicht, dass irgendjemand tatsächlich GUIs mit der WinApi erstellt. Es gibt nichtmal Layouts, was fast schon unverzichtbar ist. Es ist sehr aufwändig und es gibt damit nur lauter Probleme, die keinen interessieren und es ist praktisch unmöglich, irgendwelche fortgeschrittenen Features einzubauen. Die ganze GUI Programmierung an sich ist doch ziemlich nebensächlich. Das will man möglichst schnell und problemlos erledigen. Dabei kommen aber öfter aber irgendwelche Ideen wie "wär doch nett hier noch...". Geht aber nicht mit der WinApi, muss man erstmal tagelang programmieren und debuggen, wo die größeren Frameworks schon das meiste erschlagen würden. Du wirst wohl kaum einen Arbeitgeber finden der sagt, klar, nimm WinApi und schreib eine GUI.

    0
  • B

    Ja wie gesagt, ich bin offen für Empfehlungen.
    Es wird nur sehr sehr oft empfohlen, mit der WinAPI zu beginnen.
    Ich hab zich Jahre mit VB6 programmiert und kam super zurecht damit...und es ging alles schnell. Auch hier hab ich in manchen fällen auf die Windows API-Funktionen zurückgegriffen. Im großen und ganzen musste ich mich jedoch um die GUI gar nicht kümmern. Ich weiß, dass VB6 keinen guten Ruf...ich will damit nur sagen, dass ich gerne auf solche Programmierhilfen zurückgreife.
    Es soll aber schon eher ein Microsoft-Ding sein...bzw ne richtige Windows-Sache.
    Und das ist in Verbindung mit Visual C++ eben die MFC. Über die MFC wird auch oft geschimpft, aber das ist eben ein offizieller Weg der Windows-Programmierung mit C++. Nur leider möchte ich nur die VS Express Version für mein Hobby nutzen. Deswegen kam ja ursprünglich die Frage zu einer Alternative...ich hörte da schon von WTL, Win32++ usw. Wollte jedoch eure Meinung dazu hören. Mit Visual Basic musste ich mir über solche Dinge ja nie Gedanken machen und C/C++ kenne ich nur in Verbindung mit Konsolenanwendungen.

    Mit "richtiger Windows-Sache" meine ich natürlich auch solche Frameworks/Toolkits wie eben Win32++, weil es auf die WinAPI zurückgreift und native Windows-Anwendungen erstellt. Es soll nur nicht sowas wie Qt oder GTK sein...die Programme werden nie Linux als Ziel haben. Und auch wenn Qt auch rein für Windows empfohlen wird, ist es für mich eben keine richtige Windowsanwendung.

    Ich stelle mir die MFC so vor, dass sie alles abdeckt und man nur in extremsten Ausnahmefällen direkt eine Windows-API-Funktion einbinden muss. Gibt es hier kostenlose Alternativen, oder sind Frameworks wie Win32++ nur für simple GUIs und den Rest muss man dann sowieso wieder über die API machen?

    0
  • M

    Keine Ahnung, wie du dir das alles vorstellst... Wenn du schon weisst (wie anfangs geschrieben), dass du nur ganz simple GUIs brauchen wirst, dann nimm sowas wie WTL oder Win32++ oder ähnliches. Aber wenn du irgendwo arbeiten willst, wird dir dein Arbeitgeber wahrscheinlich vorschreiben, was du zu benutzen hast (außer es ist eine kleine Firma und es ist ein ganz neues Projekt und du darfst frei entscheiden). Und die meisten GUIs werden irgendwann mehr oder weniger zwangsläufig komplexer. Mit komplexeren Frameworks kann man oft mit sehr wenig Aufwand Features einbauen, die dem Kunden einen gewissen Mehrwert bieten. Mit der reinen WinApi (oder aber auch mit der MFC) bleibst du auf Windows 3.1 Niveau oder musst sehr viel mehr Arbeit reinstecken, womit sich die Features dann überhaupt nicht mehr lohnen. Also bleibst du auf Windows 3.1 Niveau 😉
    Ich mag die MFC auch überhaupt nicht, aber bevor man völlig sinnlos ewig viel Zeit reinsteckt, um nur paar simple Fenster und Buttons hinzubekommen, dann doch lieber das.

    0

  • ...

    0
  • B

    Ähm ... Qt benutzt immer wo möglich die nativen Steuerelemente der Plattform ...

    Sicher? Meines Wissens zeichnet Qt seine Steuerelemente selbst. Zeichnet jedoch perfekt die nativen Steuerelemente nach. Aber vielleicht hat sich da ja was geändert.
    Von den großen Cross-Plattform-Frameworks, welches unter Windows tatsächlich nativ auf die WinAPI greift, ist mir jetzt nur wxWidgets bekannt.
    wxWidgets ist quasi eine Ummantelung der WinAPI, wie etwa die MFC. Qt macht sein ganz eigenes Ding.

    Mit wxWidgets wäre mein Problem ja eigentlich gelöst. Wie gesagt hab ich jedoch schon oft gelesen, dass es ein zusammengeschustertes Framework ist, welches eine schlechte Doku hat und auch noch langsam läuft. Wenn ich schon C++ verwende, möchte ich nicht unbedingt ein langsames Framework, welches mir das Programm ausbremst. Oder sind das alles nur Gerüchte? 🙂
    Bei wxWidgets wäre ich aber garantiert auf der sicheren Seite, dass es das Projekt noch lange gibt. Viele Frameworks für Windows brachen ihre Entwicklung ja einfach plötzlich ab 🙂

    @Mechanics:
    Nee, das ist wirklich nur reines Hobby. Ich werde C++ beruflich auch weiterhin nur für Nicht-GUI Dinge benötigen 🙂 Frameworks wie Qt sind vielleicht für pure Softwarefirmen interessant, aber das ist ja nicht mein Arbeitsgebiet 🙂

    0

  • ...

    0
  • B

    Ich weiß nicht, was Du unter 'in eine PictureBox zeichnen' verstehst ... aber vom Prinzip her geht es bei der ganzen GUI-Programmierung doch immer darum, in ein Fenster zu zeichnen.
    Wenn ich mich recht erinnere, geht es gleich in einem der ersten Tutorials zu Win32++ darum, mit der Maus in einem Fenster rumzuzeichnen.
    Dass man das dann auch irgendwie drucken kann, steht außer Frage, WIE das allerdings zu bewerkstelligen ist, weiß ich nicht, weil ich mich mit dem Thema noch nie befasst habe. Deshalb weiß ich auch nicht, ob Win32++ da was fertiges anbietet.
    Ebensowenig kann ich Dir sagen, ob es weiterentwickelt wird ... wenn Du immer und ständig die neuesten GUI-Features brauchst, ist ein professionelles Werkzeug von Microsoft oder Borland wahrscheinlich besser geeignet.
    Einen Dialog zur Auswahl von Dateien zum Speichern/Laden bietet die WinAPI schon fertig an, den kannst Du auch einfach aus einem Konsolenprogramm aufrufen.
    Ebenso wie einige andere je nach Bedarf nützliche Dialoge:
    http://msdn.microsoft.com/en-us/library/windows/desktop/ff468806(v=vs.85).aspx

    Die Oberfläche für die GUI kann man schön mit einem Ressourceneditor erstellen (ich nehme ResEdit dafür, es gibt sicher noch andere), die Programmierung dann mit Win32++.
    Wenn ein wenig Grundlagenwissen über Win-Programme (Fenster, Messages, Message-Handling) vorhanden ist, kann man sich recht schnell in Win32++ einarbeiten.

    Bei Frameworks wie der MFC oder Borland ist nach meiner Einschätzung weniger Grundlagenwissen erforderlich - man kommt wohl (zumindest zu Beginn) schneller ans Ziel, weil man einige Zusammenhänge gar nicht begreifen muss.

    0
  • B

    Die WinApi besitzt eine reine C-Schnittstelle. Man muss Strukturen füllen, WinApi-Funktionen aufrufen, Nachrichten auswerten und ggfs. selbst senden. Ist heute eine Ochsentour, aber nahe an den Grundlagen jeder GUI. Nichst spricht gegen den Einsatz der WinApi aus einem in C++ geschriebenem Programm.

    MFC und Borland haben etwas mehr Objektorientierung draufgesattelt. Der Resourcen-Editor und -Compiler der WinApi tun das aber auch recht gut. Will man mehr, wäre C# zu empfehlen. Dort wird alles mit Objekten, Eigenschaften, und Ereignisroutinen geregelt, was sehr übersichtlich ist. C# bietet allerdings zwei unterschiedliche GUIs: WindowsForms und WPF, wodurch die Einarbeitung etwas mühsam sein kann. Die anderen genannten GUI-Bibliotheken sind ähnlich.

    Was du nun nehmen willst, musst du selbst entscheiden!

    0
  • B

    Hi,

    also vielen Dank an euch alle, für die vielen Tips. Ich hab ja auch seit dem letzten Post wieder nachgelesen und nachgedacht...die Sache mit einem Framework wäre schon besser für mich. Für spezielle Dinge kann ich ja immer noch auf die Windows-API greifen, so machte ich es ja auch zu VB6 Zeiten. Aber was die GUI und etwas Schnick Schnack drumherum betrifft, da bleib ich wohl doch bei der angenehmeren Methode, also einem ausgereiften Framework.
    MFC fällt hier wegen der Lizenz schon mal raus und zu WTL bekomme ich kaum Information. Dann bleibt eigentlich nur noch wxWidgets.

    Gut, viele Leser werden sich fragen, warum ich nicht einfach Qt nehme 😃
    Ich würde sehr gerne Qt nutzen, jedoch wage ich mich da aus folgenden Gründen nicht so ran:
    Man sagt, dass es kein richtiges C++ sei sondern ein Mischmasch ähnlich wie C++/CLI. Also Qt hält sich angeblich nicht so wirklich an den Standard.
    Dann gibt es da noch diesen Precompiler oder MOC...man hört, dass der selbstgeschriebene Code nicht direkt übersetzt wird, sondern durch einen Precompiler wieder verändert wird und das Ergebnis hiervon erst in Maschinencode kompiliert wird. Man weiß also nicht genau, wie das Programm überhaupt arbeitet, weil der eigene Code ja nicht der wirkliche ist.
    Das sind keine Behauptungen von mir, das ließt man nur so im Internet. Ich hab schon oft versucht mehr Infos darüber rauszufinden...aber die Leute werfen immer nur diese Behauptungen in den Raum, ohne ausführlicher Erklärung wie das alles genau zu verstehen ist.

    Auch dir Belli, danke für deine schöne Erklärung zu Win32++. Die PictureBox ist ein Steuerelement bei Visual Studio bzw. war es bei VB6 und ist es bei VB.NET. Im Grunde ist es nichts anderes als ein Steuerelement, was Bilder darstellen kann. Man kann auch darin Zeichnen, das Bild speichern usw. Eigentlich nichts besonderes, aber hätte ja sein können, dass man mit der WinAPI sowas erst selbst zusammenproggen muss...aber anscheinend kann man sich die ganzen fertigen Steuerelemente direkt über die API zusammensammeln 🙂

    0
Anmelden zum Antworten