Hallo,
ich habe gerade mit winapi angefangen und möchte mir eine oberfläche
erstellen. Dazu habe ich ein Beispielprogramm gefunden, welches mir das
Fenster erstellt
Dazu habe ich eine Frage, kommen alle Elemente die ich in der Oberfläche
erstelle in die selbe Callback Funktion (LRESULT CALLBACK WndProc)? Oder
kann man das noch irgendwie aufteilen? Also pro element eine Funktion
oder ähnlich?
Momentan habe ich nur zwei Buttons dort drinn. Aber wenn noch mehr
Elemente (z.B. RadioButton oder Tastatureingabe oder schreibfenster oder
...) kommen, kann das ja ziemlich unübersichtlich werden.
Ich weiss ja nicht, wie komplex Deine Oberfläche werden soll, aber für
alles, was über zwei Knöpfe hinausgeht, würde ich nicht winapi
verwenden. Es ist natürlich sinnvoll, das Beispielprogramm zu verstehen,
um zu wissen, wie die Hauptnachrichtenschleife in Windows-Programmen
funktioniert. Für den eigentlichen Job würde ich aber ein Framework
verwenden. Das nimmt Dir viel Arbeit ab und kapselt viele Details (wie
eben auch die Nachrichtenschleife).
Ich mache das mit MFC, einfach weil ich das vor 20 Jahren gelernt habe
und Portabilität auf andere Plattformen normalerweise kein Thema ist.
Ich trenne allerdings strikt GUI-Code und den eigentlichen Arbeitscode,
um eben doch portieren zu können, falls erforderlich.
Zu den möglichen Frameworks hat jeder seine Meinung. Konsens ist wohl,
dass ein Neueinsteiger heute nicht mehr mit MFC anfangen sollte, sondern
eher Qt lernen sollte. Für kleinere Projekte gibt es einfachere
Alternativen. Du sagst auch nicht, ob Du einen Compiler kaufen kannst
(MFC gibt's soweit ich weiss nur in der kommerziellen Version von Visual
Studio, Qt ist umsonst) oder ob alles umsonst sein muss.
Dann gibt's noch die Frage, ob Du Dich auf C# und .net einlassen
möchtest (und damit an Microsoft-Technologie gebunden bist) - dann
stehen andere Alternativen offen. Für mich musste ich diese Frage mit
Nein beantworten, aber jeder Jeck iss anders.
Und falls Du wirklich nur zwei Knöpfe und ein Eingabefeld brauchst:
Mach's mit winapi, Du lernst auf jeden Fall was dabei.
Wenn Du tatsächlich den sehr steinigen Weg gehen möchtest,
Windows-GUI-Anwendungen mit der Win32-API zu schreiben, kann ich Dir nur
die Lektüre eines Buches nahelegen:
Charles Petzold "Windows-Programmierung: Das Entwicklerhandbuch zur
WIN32-API".
ISBN 3860631888
(das ist zwar fast zwanzig Jahre alt, aber die API für
GUI-Programmierung und die dahinterstehenden Konzepte haben sich seitdem
nicht geändert)
Üblicherweise empfehle ich keine übersetzten Bücher, hier aber stammt
die Übersetzung von Arne Schäpers, der bereits das deutsche Handbuch von
Borlands Turbo-C 2.0 geschrieben hatte, und das war exzellent.
Das englischsprachige Original des Petzold ("Programming Windows®, Fifth
Edition") findest Du unter der ISBN 157231995X.
Beide Bücher sind natürlich nur noch antiquarisch erhältlich.
--
Ich verdiene seit über einem Vierteljahrhundert meinen Lebensunterhalt
unter anderem mit der Windows-Programmierung, und ich bin sehr froh,
GUI-Anwendungen nicht auf diese Art und Weise schreiben zu müssen. Das
habe ich in den ersten paar Jahren (beginnend mit Windows 3.0) gemacht,
und es ist sicherlich gutes Grundlagenwissen, das einem hilft, zu
verstehen, warum eine bestimmte C++-Klassenbibliothek auf eine bestimmte
Art und Weise aufgebaut ist --- aber nicht jedes Grundlagenwissen, das
in einem Computer steckt, muss man unbedingt haben, wenn man einfach nur
Programme dafür schreiben will.
Windows-GUI-Anwendungen würde ich mit einer C++-Klassenbibliothek
schreiben, und da das Thema "Portabilität" nicht komplett uninteressant
ist, würde ich eine auf mehreren Plattformen verfügbare Bibliothek
wählen. Die "Platzhirsche" sind hier QT und wxwidgets.
Ich selbst arbeite überwiegend mit der nicht portierbaren MFC; die zu
lernen rate ich nicht. Daß ich sie nutze, ist historisch bedingt; als
ich damit anfing, gab es keine Alternativen. Als "Exit-Strategie" sehe
ich in diesem Fall wxwidgets, weil einige strukturelle Konzepte der MFC
ähneln und von daher der Umdenkaufwand nicht so groß ist, wie er es bei
QT wäre.