# Start mit einem GUI in C++



## Freddycbv (23. Dezember 2010)

Liebe Community,

Ich habe vor einem halben Jahr angefangen, in C zu programmieren,
bin jedoch schon bald zu C++ umgestiegen, da es mir mehr Möglichkeiten bietet. (VB und Python haben mir nicht gefallen, waren mir zu einfach, und zu schreibaufwändig)
Jedenfalls konnte ich mir nun schun die Grundlagen aneignen, jedoch wurde mir die Konsolenprogrammierung langsam zu langweilig und umständlich, 
da man mit einer Konsolenanwendung schlecht interagieren kann.

Also habe ich mich im Internet ein bisschen ins Thema GUI eingelesen, und habe vor einer knappen Woche mit WinAPI angefangen.
Als ich mir jedoch einige Threads in diesem Forum angeschaut hatte, wurde hier u. A Qt empfohlen, 
da es einfacher sei. (muss sagen,dass der Start in die Windows API nicht einfach war, ein einfacher Schnellstart ist mir lieber )

Also meine Frage:

Mit welcher GUI würdet ihr an meiner Stelle anfangen??
Soll ich bei WinAPI bleiben, oder neustarten???
Wenn QT, kennt ihr gute deutscheTutorials (bzw. Bücher),
meine Englischkenntnisse sind noch nicht so ausgeprägt(bin in der 8.Klasse)

Schonmal vielen Dank für Antworten,

Freddycbv


----------



## bingo88 (23. Dezember 2010)

Ich würde dir zu Qt raten. WinAPI ist schon ordentlich Quälerei 
Zu deutschen Tutorials kann ich dir leider nichts sagen, da ich meist nur mit englischen Quellen arbeite


----------



## Freddycbv (23. Dezember 2010)

Vielen Dank für die schnelle Antwort,
werde mir es mal runterladen

Bin ich hier richtig???
Downloads — Qt - A cross-platform application and UI framework

Kann man mit WinAPI oder mit Qt mehr anfangen???

Freddycbv


----------



## Fragile Heart (23. Dezember 2010)

Ahoi,



Freddycbv schrieb:


> Ich habe vor einem halben Jahr angefangen, in C zu programmieren, bin jedoch schon bald zu C++ umgestiegen, da es mir mehr Möglichkeiten bietet. (VB und Python haben mir nicht gefallen, waren mir zu einfach, und zu schreibaufwändig)


Ohhhh, ich glaube du hast noch nicht wirklich viel mit C++ gearbeitet.  Es wird noch lustig wenn du festellst wie dir die anderen Programmiersprachen entgegen kommen und du auf all diesen Luxus in C/C++ verzichten musst. Aber egal, das ist ein anderes Thema.



Freddycbv schrieb:


> Also meine Frage:
> 
> Mit welcher GUI würdet ihr an meiner Stelle anfangen??
> Soll ich bei WinAPI bleiben, oder neustarten???
> ...


Diese Fragen kann ich eigentlich erstmal nur mit einer Gegenfrage beantworten. Was möchtest du denn genau machen? Wenn es darum geht einige kleinere Tools zu Programmieren oder später mal in den Bereich Anwendungsentwicklung zu gehen, dann ist QT die beste Wahl. Willst du ehr in den Bereich Spiele gehen oder HPC, dann solltest du vielleicht doch erst mal bei WinAPI bleiben, denn auch wenn du sie nachher nicht mehr wirklich verwendest, sie kann ein wirklich ankotzen und die Schlaflosennächte unter den ganzen Handles wird du dein Leben lang nicht mehr vergessen  , brauchst du eine Ahnung davon wie diese genau funktioniert, denn alle Lib setzen auf ihr auf und wenn es um Performance geht, dann musst du da runter und schuften.

Ich hab erst WinAPI, damals noch 16 Bit, und dann MFC bzw QT gemacht. Hat sich gelohnt wie ich finde.

Ach und unbedingt am Englisch arbeiten, sehr wichtig.


----------



## Freddycbv (23. Dezember 2010)

Vielen Dank für deine Antwort,

hmm, schwierige Sache...
Zur Entscheidung habe ich noch ein paar Fragen

-Warum ist Qt besser für Anwendungen, WinApi besser für Games???
 Qt soll  mehr möglichkeiten bieten und einfacher sein, WinAPI hat
 mehr   Performance, hab ich das Richtig verstanden?
-Wenn ja, ist WinAPI viel schneller???

Ein guter Grund für qt ist für mich die plattformunabhängigkeit, 
hab zwar bisher immer mit Windows gearbeitet, Linux interessiert mich aber schon, also

-Kann man mit WinApi wirklich nicht plattformunabhängig programmieren???

Meine Zielrichtung geht schon zu einem Spiel, vorher hatte ich jedoch vor einige kleinere (aber nützliche) Programme zu programmieren;
allein durch Lektüre kann ich nicht lernen.

Freddycbv


----------



## Fragile Heart (23. Dezember 2010)

Also wenn du Plattformunabhängig sein willst dann QT! WinAPI ist nur für Windows gedacht. 

Warum ist die WinAPI besser für Games ist eigentlich ganz einfach zu beschreiben. Jedes Framework, sei es QT, .Net oder was auch immer, um letzt endlich WinAPI calls durchführen und schon alleine aus diesen Punkt ergibt sich das du mit der WinAPI in der Regel schneller bist. Das trifft sicherlich nicht immer für alle Sachen zu und wer weiß was sich MS da noch so alles ausdenkt, aber um Leistung aus Windows herraus zu prügeln (mit kitzeln hat das nichts mehr zu tun ) musst du wissen was da wie funktioniert.

WinAPI ist nervig und aufwendig, aber in gewisserweise auch sehr lustig.


----------



## bingo88 (23. Dezember 2010)

Die WinAPI ist übrigens auch C, Qt C++. Bei Qt gibt es also "echte" Objekte (Fenster inklusive aller Kindelemente), während bei der WInAPI nur irgendwelche Strukturen auf Wanderschaft gehen. Da steckt also auch ein ganz anderes Abstraktionslevel hinter. Und so viel schneller ist die WinAPI jetzt auch wieder nicht. Qt setzt ja auch auf der WinAPI (im Falle von Windows) auf, die können ja auch nur mit dem Arbeiten, was das OS bereit stellt.


----------



## Fragile Heart (23. Dezember 2010)

Der Geschwindigkeitsunterschied hängt immer davon ab was man macht. Aber ich denke das führt hier zu weit.


----------



## Bauer87 (23. Dezember 2010)

WinAPI setzt sehr tief in Windows an. Auf Anwendungsebene (v.a. mit C++) ist .NET wohl vorzuziehen. (Warum werden Spiele eigentlich immer mit WinAPI in Verbindung gebracht? Praxisnäher wäre es da, eine existierende Engine an eigene Bedürfnisse anzupassen.) Wichtig ist, dass man sich mit WinAPI auf Windows und mit .NET immer noch auf Microsoft (inklusive Smartphone-Systemen, die ja eigentlich kein Windows sind) festlegt.

Qt ist sehr gut strukturiert, bietet alles, was man so braucht und ist einfach zu lernen. Zudem läuft es wirklich auf jeder relevanten Plattform vom PC (Windows, MacOS und Linux) bis zu Handys (hier leider momentan nur Nokia, wobei ein Android-Port in Mache sein soll).

Geschwindigkeitsunterschiede merkt man durch die gewählte Bibliothek kaum – da hat der Rest des Systems zu viel Einfluss. Absolut dürfte man mit Qt wohl schneller laufende Programme erzeugen können (weil Windows halt langsamer ist als Linux), aber das liegt dann nicht an Qt. Da macht es einen größeren Unterschied, welchen Treiber du für deine Festplatte installierst.


----------



## bingo88 (23. Dezember 2010)

Man nutzt bei Spielen eigentlich nur WinAPI um das Fenster zu erzeugen. Der Rest läuft dann über die Grafik-API (DirectX, OpenGL, ...).


----------



## Skysnake (23. Dezember 2010)

Naja, dann geb ich auch mal kurz meinen Senf dazu ab, da ich mit QT selbst im Moment arbeiten muss.

Also erstmal ne Sache. Fragile Heart meinte das im HPC Bereich WinAPI eingesetzt würde. Also ich kann mir das bei bestem Willen nicht vorstellen. 1. Wird im HPC Bereich normal nie Windows eingesetzt, womit WinAPI schonmal rausfällt, und dann kommt noch dazu, das es halt nur unter windows läuft, was dort auch ein KO Kriterium ist, da halt die meisten (fast alle) Systeme auf Linux aufsetzen.

Du solltest dir erstmal überlegen, was du machen willst. Daraus ergibt sich eigentlich sehr schnell was du verwenden sollst.

Nimm WinAPI wenn:
1. Deine Benutzer auf Windows Systeme setzen, und dir portabilität egal ist
2. Die User nicht damit gequält werden sollen sich QT zu installieren (überfordert den normalen Windows user)

Nimm QT wenn:
1. Deine Benutzer auch Linux einsetzen, bzw nur Linux
2. Du deinen Usern zutraust QT zu installieren (ist gegeben, wenn sie Linux nutzen)
3. ODER deine User Windows nutzen, du aber eine Anwendung schreibst die einen ganz speziellen (wissenschaftlichen) Einsatzzweck besitzt und du daher den Umstand in kauf nehmen kannst was extra zu installieren.


----------



## bingo88 (23. Dezember 2010)

Skysnake schrieb:


> 2. Die User nicht damit gequält werden sollen sich QT zu installieren (überfordert den normalen Windows user)


Hmm... musste ich noch nie machen? Ich hab da immer nen paar DLLs im Setup-Projekt, die das übernehemen (Beispiel VLC Player)


----------



## Skysnake (23. Dezember 2010)

Ja gut, wenn du das kannst ist das natürlich kein Ding


----------



## bingo88 (23. Dezember 2010)

Qt ist schon ne gute Wahl, zumal das SDK ja alles mitbringt (IDE, Compiler, ...)


----------



## Skysnake (24. Dezember 2010)

dafür gibts nen SDK? 

Ich programmier das nur mit den ganz stink normalen QTMethoden in C++ halt.

Was btw ziemlich eklig ist, wenn mans mit MPI zusammen einsetzt


----------



## bingo88 (24. Dezember 2010)

Skysnake schrieb:


> dafür gibts nen SDK?
> 
> Ich programmier das nur mit den ganz stink normalen QTMethoden in C++ halt.
> 
> Was btw ziemlich eklig ist, wenn mans mit MPI zusammen einsetzt


Japp, sogar mit ner IDE (Qt Creator) mit der man auch Forms designen kann 
Download unter qt.nokia.com (gibt's aber auch im Repository der meisten Linux-Distributionen)


----------



## bingo88 (24. Dezember 2010)

Doppelpost (Seite hat nicht geladen)


----------



## Skysnake (24. Dezember 2010)

So wies aussieht, kennst du dich mit QT aus. Hätte an dich daher mal ne Frage.

Ich hab ein MPI Programm, das die Wärmeverteilung auf einer Platte berechnet. Wie kann ich denn dafür Sorgen, das QT die Daten in nem Array ausgibt, sobald es fertig berechnet ist? Und wie kann ich den QT Prozess mit den MPI Prozessen syncronisieren?


----------



## Fragile Heart (24. Dezember 2010)

Skysnake schrieb:


> Fragile Heart meinte das im HPC Bereich WinAPI eingesetzt würde. Also ich kann mir das bei bestem Willen nicht vorstellen. 1. Wird im HPC Bereich normal nie Windows eingesetzt, womit WinAPI schonmal rausfällt, und dann kommt noch dazu, das es halt nur unter windows läuft, was dort auch ein KO Kriterium ist, da halt die meisten (fast alle) Systeme auf Linux aufsetzen.


Naja, muss ich vielleicht etwas relativieren. Wir arbeiten hier an Software für kleine "Super Computer" wie mein Chef das immer bezeichnet. Die setzen halt alle auf Windows. 

Was die Leistungsunterschiede angeht, so ist der Unterschied von QT zu WinAPI nicht so groß, aber von .Net zu WinAPI riesig.


----------



## Skysnake (24. Dezember 2010)

Naja, was heist "kleine" Supercomputer? Supermicro Maschinen? Cluster bis welcher Größe? Welches Verbindungsnetz setzt ihr ein?

Und was für Software schreibt ihr? Hätte da eventuell dann die eine oder andere Frage an dich


----------



## Fragile Heart (24. Dezember 2010)

Werden wir hier dann nicht Off Topic?  Wenn du Fragen hast immer raus damit.


----------



## NoFootCancan (25. Dezember 2010)

Naja, ich gebe jetzt auch mal meinen Senf mit dazu.

Ich habe für eine Zeit lang WinAPI gemacht; nur, wie bereits gesagt, es ist recht kompliziert im Vergleich zu .NET (WinForms) und Qt. Von Qt habe ich persönlich weniger Ahnung, ich habe eine Zeit lang mit WinForms gearbeitet. Das ist aber auch ein Krampf, bis man sich da eingearbeitet hat, weil MS zunächst mal C++ teilweise über den Haufen geschmissen hat und man sich an die ganzen ^s und <>-Arrays, genau wie die for each-Schleifen gewöhnen muss. 
Also, nach allem was ich gehört habe, ist Qt wahrscheinlich für dich die beste Wahl, es sei denn, es geht um kompromisslose Performance auf Windows-Rechnern (Spiele etc.).
Ist auch schön, dass du bei Cpp bleibst. Ist eigentlich eine nette Sprache und wenn man dann bei anderen Sprachen anfängt, hat man ein ganz unsicheres Gefühl weil man sich die Vererbungen und Zugriffsrechte, die man sich so schön zurechtgelegt hat, gar nicht braucht.

Viel Glück und Spaß!
Frohes Fest,
NFC


----------



## Freddycbv (27. Dezember 2010)

Vielen Dank für eure Antworten!!

Ich glaube WinAPI ist für mich erstmal die bessere Wahl, da ich mich nun schon etwas reinprogrammiert habe, und ich ehrlichgesagt es etwas umständlich finde, bei Qt vor der Verwendung es erstmal zu installieren.
(Als Anwender natürlich, als Ersteller ist's klar)
Ich kann ja immer noch umsteigen, doch Windows bleibt momentan erstmal führendes OS.
Gerne lass ich mich (vielleicht sogar von mir) noch umstimmen, 
doch ich werde mich non erstmal mit WinApi beschäftigen.

Wenn auch etwas OffTopic:  

Ich nutze als Entwicklungsumgebung CodeBlocks, kennt sich jemand damit aus????
Ich weiß, meine Frage ist vielleicht eine Noob-Frage, doch damit wurde ich noch nie konfrontiert.
Ich habe nämlich das Problem, das ich nicht weiß wie man Ressourcen in Code::Blocks *korrekt* einbindet,
beim kompilieren der folgenden Ressourcendatei kommen nämlich gleich zwei Probleme....(Sorry, wie kann man hier Einrückungen machen??)

_1 :#include <windows.h>
2 :#include "resource.h" 
3 ://///////////////////////////////////////////////////////////////
4 ://
5 :// Menü
6 :// 
7 :IDR_MENU1 MENU
8 :BEGIN
    9 :    POPUP "Datei"    
    10:    BEGIN        
        11:        MENUITEM "Öffnen",             ID_FILE_OPEN        
        12:        MENUITEM "Speichern",          ID_FILE_SAVE        
        13:        MENUITEM "Ende",               ID_FILE_EXIT    
    14:    END    
    15:    POPUP "Optionen"    
    16:    BEGIN        
        17:        POPUP "Optionen"        
        18:        BEGIN            
            19:            MENUITEM "Option&1",       ID_OPTIONS_OPTIONS_OPTION1            
            20:            MENUITEM "Option&2",       ID_OPTIONS_OPTIONS_OPTION2        
        21:        END    
    22:    END    
    23:    MENUITEM "Über",                   ID_ABOUTEND 24://///////////////////////////////////////////////////////////////
25://
26://Icon
27://
28:ID_ICON              ICON     "goofy.ico"_

Also es gibt hierbei zwei Probleme:

1.Woher bekomm ich die Datei 'resource.h'(Indem die Konstanten gespeichert sind)? 
(Sie wurde befindet sich nicht im Projektordner)
2.Es gibt beim kompilieren mehrere(bzw immer nur einen, da der Compiler beim ersten Fehler hängenbleibt)Syntaxfehler.(1. in Zeile11)

Vielleicht weiß jemand ja des Rätsels Lösung.

Vielen Dank für die Antworten

Freddycbv


----------



## Dragonix (27. Dezember 2010)

> und ich ehrlichgesagt es etwas umständlich finde, bei Qt vor der Verwendung es erstmal zu installieren.
> (Als Anwender natürlich, als Ersteller ist's klar)


Du musst als Anwender Qt nicht installieren, du musst als Entwickler blos die Qt-irgenwas.dll mit ausliefern..
Qt is toll!!


----------



## Freddycbv (27. Dezember 2010)

Aha,

dann hab ich das woohl falschverstanden:



> Nimm QT wenn:
> 1. Deine Benutzer auch Linux einsetzen, bzw nur Linux
> 2. Du deinen Usern zutraust QT zu installieren (ist gegeben, wenn sie  Linux nutzen)
> 3. ODER deine User Windows nutzen, du aber eine Anwendung schreibst die  einen ganz speziellen (wissenschaftlichen) Einsatzzweck besitzt und du  daher den Umstand in kauf nehmen kannst was extra zu installieren.



oder etwa nicht ?????

Was muss man denn nun als Anwender machen????


----------



## bingo88 (27. Dezember 2010)

Als normaler Anwender brauchst du eigentlich nichts zu machen (außer die passende Version des Programms zu nutzen - Windows, Linux, Mac, ...).

Als Entwickler musst du dich halt darum kümmern, alle benötigten Dateien mit auszuliefern.

Qt besitzt außerdem eine eigene IDE mit Designer, basiert auf C++ (hat also Klassen und unterstützt Vererbung) und hat der auf C-basierenden WinAPI einiges voraus.


----------



## Fragile Heart (27. Dezember 2010)

Die Resource.h wird in der Regel vom Resourcen Editor gepflegt und enthält Konstanten die als Schnittstelle zwischen Resourcen und Code dienen (Befehlskonstanten und Bezeichner). Sie sollte sich im selben Verzeichnis wie die Resourcen Datei befinden.

Wenn dem nicht so ist, dann geb mir mal bescheid und ich gebe dir mal ein Muster (zu faul das jetzt zu machen  )


----------



## bingo88 (27. Dezember 2010)

Kann den Codeblocks damit überhaupt umgehen? Das ist ja eigentlich ne sehr MS-spezifische Sache


----------



## Fragile Heart (28. Dezember 2010)

Diese Frage kann ich dir leider nicht beantworten, nur scheinen die ja zumindest irgendeine Art von Editor für sowas zu haben.


----------



## Freddycbv (28. Dezember 2010)

Ich sollte lieber mal nachdenken(bzw. nachschauen), bevor ich hier ne Frage schreib.....

Die Datei, in der die Konstanten erstellt wurden, fand ich nach einigem Suchen auf der Seite des Turrorials.Lesen muss auch gelernt sein....
Habe jedoch nocheine Frage dazu...

Dazu mal die gefundene Datei:

 //resource.h - Headerdatei 

#define ID_STRING_OPEN                  1
#define ID_STRING_SAVE                  2
#define ID_STRING_OPTION1 3
#define ID_STRING_OPTION2               4
#define ID_STRING_ABOUT                 5 
#define IDR_MENU1                       101 
#define ID_ICON                         111 
#define ID_FILE_OPEN                    40001
#define ID_FILE_SAVE                    40002
#define ID_FILE_EXIT                    40003
#define ID_OPTIONS_OPTIONS_OPTION1      40004
#define ID_OPTIONS_OPTIONS_OPTION2      40005
#define ID_ABOUT                        65535

Sowas kann man doch eigentlich selber machen, also z.B. von 1-99 Zeichenketten
und von 100-199 die verschiedenen Menünamen, usw...
Es ist also egal, welche Nummer die verschiedenen define-Konstanten haben, 
oder irre ich mich da???

Habe bisher noch nicht mit Ressourcen gearbeitet, also sorry.
Macht das Verändern einfacher und schneller, 
(???Der Compiler kompiliert dann nur noch die .rc Datei, oder????)

Vielen Dank für Antworten,

Freddycbv

PS: Würd ehrlichgesagt lieber was anderes als CodeBlocks benutzen, ist aber schön schnell...
(Mit Microsoft VS dauert das kompilieren eines Hello-World-Programmes 
ca. 20 sec, zu lang für mich....)


EDIT::: Achso, mit der Datei hat dann alles geklappt, bin nur etwas anderes von CodeBlocks geewöhnt.
           Normalerweiße steht in den Fehlermeldungen  immer schön viel drinn, also eher "ID_FILE_OPEN was not 
           decleared in this Scope" oder so ähnlich... "Syntax-error" isn bissle smart


----------



## bingo88 (28. Dezember 2010)

20 sek ist allerdings was lang 
Kann ich allerdings nicht bestätigen


----------



## Freddycbv (28. Dezember 2010)

bingo88 schrieb:


> 20 sek ist allerdings was lang
> Kann ich allerdings nicht bestätigen



Mmmh, hast wohl auch nen neueren als den hier:

Mein PC:
-Graka:   Nvidia Riva TnT 64
  -Ram:     512MB SDRam
  -CPU:     Pentium 3 @1Ghz
  -MB:       Compaq Deskpro (Chipsatz: Intel Solano i815)
-Röhrenmonitor mit laut Everest einer max. Auflösung von   [FONT=&quot]1280 * 1024[/FONT]

Am 24.01 kommt  was neues her....


----------



## bingo88 (28. Dezember 2010)

Okay, das ist wohl wahr (Athlon XP 2400+)  Ich hab nix gesagt


----------

