A. R. schrieb:
> In C habe ich gelernt, dass der Header benötigt wird um dem Programm
> alle Funktionen in Form von Prototypen mitzuteilen.
Na ja. NIcht alle.
Diejenigen, die in diesem Header stehen.
Man wird ja sinnvollerweise für jede Funktionsgruppe eine eigene C Datei
und eine dazugehörige Header Datei machen. Dann sind im Header nur die
Funktionen (und Strukturen etc), die zu dieser Funktionsgruppe gehören
und im C File dann auch nur die Implementierungen der Funktionen, die zu
dieser Funktionsgruppe gehören.
> Während dem
> compilieren wird der Header quasi vor der .cpp-Datei eingefügt. Dort
> können also auch defines und Strukturen festgelegt werden.
In a nutshell: Ja, kann man so sagen.
#include ersetzt einfach die Zeile in der es steht mit dem Inhalt der
Datei, die im include angegeben ist.
> In C++ wurde dies fortgesetzt. Also im Header wurde die Klasse mit
> abgeleiteten Klassen, Konstruktor, Destruktor sowie alle Membervariablen
> und Methoden definiert.
In groben Zügen: ja.
Stell dir einfach den Begriff Prototyp etwas weiter gefasst vor. In C
waren das nur Funktionen und Strukturen, in C++ ist es einfach der
prinzipielle Aufbau einer Klasse, bestehend aus Funktionen und
zugehörigen Daten.
> Das heißt nach meinem momentanen Wissensstand, dass nachdem ich die
> Headerdatei einer Klasse eingebunden habe ich alle Methoden der Klasse
> verwenden kann, ohne vorher einen Protypen zu schreiben.
Die Klassendeklaration ist sozusagen der Prototyp dieser Klasse.
> In dem Beispiel aus dem Tutorial ist es nun so, dass in dem Header
> mehrere Klassen erstellt werden.
Ja, macht ja nix.
Du hast ja auch in deinen C-Header Files meherer Funktionsprototypen
gehabt.
> Warum ist dies so?
Weil diese Klassen zb thematisch zusammengehören. Das ist der übliche
Fall.
> Kennt das Programm
> nicht schon durch den Header <afxwin.h> alle verwendeten Methoden?
Nur die, die vom Windows kommen.
Aber das sind ja
*) nicht alle Klassen, die dir von der MFC zur Verfügung gestellt werden
*) und auch nicht die Klassen, die du selber geschrieben hast.
> Kann es sein, dass die Klassen "von mir" komplett neu angelegt werden?
Kann nicht nur so sein, sonder ist so. Deine Klassen sind ja nicht
Bestandteil von Windows oder der MFC
> Wenn ja von wem werden die Methoden dann später aufgerufen?
Von demjenigen, der sie aufruft. Im Regelfall ist das der Code, den du
schreibst oder eine andere Klasse aus dem MFC Framework, welches die
Detail-Arbeit ausgelagert hat, weil es diese gar nicht kennen kann.
> Header:
>
1 | > #include <afxwin.h> //Schritt 1
|
2 | >
|
3 | > class CMyApplication : public CWinApp //Schritt 2
|
4 | > {
|
5 | > public:
|
6 | > virtual BOOL InitInstance();
|
7 | > };
|
8 | >
|
Das Applikationsobjekt.
Muss es immer geben und implementiert dein Programm. Diese Klasse
fungiert wie eine Art Schachtel in der sich alles abspielt, was mit
deinem Programm zu tun hat.
>
1 | > class CMyWindow : public CFrameWnd //Schritt 3
|
2 | > {
|
3 | > public:
|
4 | > CMyWindow();
|
5 | > };
|
6 | >
|
Das Frame-Window. Wird vom MFC Framework erzeugt und hat die Aufgabe das
Hauptfenster einer Applikation zu sein.
> Ggf. vermissen ich bei MFC auch einfach eine main(), die vom
> Betriebssystem aufgerufen wird und dann alles von oben nach unten
> ausführt.
Ganz genau.
Die MFC ist ein Framework. D.h. sie übernimmt die Rolle von main() und
stellt so etwas wie eine Umgebung zur Verfügung, in der
Windows-Applikationen grundsätzlich ablaufen. Dieses Framework kümmert
sich zb darum dass Windows Messages an das richtige Fenster innerhalb
deiner Applikation geschickt werden etc.
Aber natürlich kann so ein Framework nicht alles abdecken. Es ist darauf
angewiesen, dass dein Programm die Details erledigt. In der MFC wird das
so gemacht, dass aus dem Framework heraus Methoden von standardisierten
Klassen aufgerufen werden, die dann die Details ergänzen. Das ist dann
genau der Punkt, an dem deine Klassen von da oben ins Spiel kommen. Denn
die Implementieren dann genau diese Detail-Dinge.
Thread beobachten
Seitenaufteilung abschalten