Bin schon mit dieser Seite dieses Tutorials durch:
http://pronix.linuxdelta.de/C/win32/win32_4.shtml

#include <windows.h>
#include "resource.h"

LPCSTR MainClassName = "Texteditor";

// Zum Empfangen und Auswerten der messages
LRESULT CALLBACK WndProc(HWND hWnd,UINT iMsg, WPARAM wParam, LPARAM lParam);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
	// Fensterstruktur setzen
	WNDCLASSEX wc;
	wc.cbSize = sizeof(WNDCLASSEX);
	wc.style = 0;
	wc.lpfnWndProc = WndProc;
	wc.cbClsExtra = 0;
	wc.cbWndExtra = 0;
	wc.hInstance = hInstance;
	wc.hIcon = LoadIcon(GetModuleHandle(NULL), MAKEINTRESOURCE(ID_ICON));
	wc.hCursor = LoadCursor(NULL, IDC_ARROW);
	wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
	wc.lpszMenuName = MAKEINTRESOURCE(IDR_MENU1);
	wc.lpszClassName = MainClassName;
	wc.hIconSm = (HICON)LoadImage(GetModuleHandle(NULL), MAKEINTRESOURCE(ID_ICON), IMAGE_ICON, 16, 16, 0);

	// Fenster registrieren
	if(!RegisterClassEx(&wc))
	{
		MessageBox(NULL, "Windows Registrations Fehler", "Error!", MB_ICONEXCLAMATION | MB_OK);
		return 0;
	}

	// Fenster erstellen
	HWND hWnd = CreateWindowEx(WS_EX_CLIENTEDGE, MainClassName, "Texteditor", WS_OVERLAPPEDWINDOW|WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 300, 150, NULL, NULL, hInstance, NULL);
	if(hWnd == NULL)
	{
		MessageBox(NULL, "Fehler beim Erstellen des Fensters!", "Error!", MB_ICONEXCLAMATION | MB_OK);
		return 0;
	}

	// Fenster anzeigen
	ShowWindow(hWnd, iCmdShow);

	// Auf Messages reagieren
	MSG wmsg;
	while( GetMessage(&wmsg, hWnd, 0, 0) )
	{
		TranslateMessage(&wmsg);
		DispatchMessage(&wmsg);
	}

	return wmsg.wParam;
}

LRESULT CALLBACK WndProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
{
	char string[255];

	switch (iMsg)
	{
		case WM_CLOSE:
			DestroyWindow(hWnd);
		break;
		case WM_DESTROY:
			PostQuitMessage(0);
			return 0;
		case WM_COMMAND:
			switch(LOWORD(wParam))
			{
				case ID_FILE_OPEN:
					LoadString(GetModuleHandle(NULL), ID_STRING_OPEN, string, sizeof(string));
					MessageBox(hWnd, string, "Öffnen", MB_ICONINFORMATION);
				break;
				case ID_FILE_SAVE:
					LoadString(GetModuleHandle(NULL), ID_STRING_SAVE, string, sizeof(string));
					MessageBox(hWnd, string, "Speichern", MB_ICONINFORMATION);
				break;
				case ID_OPTIONS_OPTIONS_OPTION1:
					LoadString(GetModuleHandle(NULL), ID_STRING_OPTION1, string, sizeof(string));
					MessageBox(hWnd,string, "Option 1", MB_ICONINFORMATION);
				break;
				case ID_OPTIONS_OPTIONS_OPTION2:
						LoadString(GetModuleHandle(NULL), ID_STRING_OPTION2, string, sizeof(string));
						MessageBox(hWnd,string, "Option 2", MB_ICONINFORMATION);
				break;
				case ID_\1:
					LoadString(GetModuleHandle(NULL), ID_STRING_ABOUT, string, sizeof(string));
					MessageBox(hWnd,string, "Über", MB_ICONINFORMATION);
				break;
				case ID_FILE_EXIT:
					DestroyWindow(hWnd);
				break;
			}
		break;
	}

	return DefWindowProc(hWnd, iMsg, wParam, lParam);
}

Ein Haufen Sachen sind für mich nicht nachvollziehbar.
Das meißte habe ich in diesem Turorial nur
heuristisch zum reinpasten gelernt

Zum Beispiel verstehe ich nicht, wieso man ein Fenster
bei Windows registriert mit einem struct, dass man
al Argument zum Registrieren übergibt und dann noch
das Fenster erstellt!?

Jede 2e Zeile in diesem Tutorial heißt es "dafür schauen sie
bitte in der msdn nach", "dazu genauer unter der msdn" ich
meine, wenn man diese Andeutungen weglässt, hat man bloß noch
code zum pasten, jetzt mal im Ernst!

Aus einem msdn Artikel wurde ich in meinem ganzen Leben noch nicht schlau!
Ich schaffe es nicht einmal, per Google eine Erklärung
zum typedef LRESULT zu finden, wozu er a ist bzw. was er bringt.
Wieso LRESULT CALLBACK? Ist doch nur eine simple Funktion,
die durch wc ausgelöst wird.
Was bringt der MainClassName? Was bringt Translate Message?

Ich will zuerst mal einen simplen Texteditor coden.
Verdammt, ich weiß nichtmal, wie ich das Problem schildern soll!!!

// edit
Hab jetzt ne Runde recharchiert und kann das meißte jetzt nachvollziehen.
Ein Problem fällt mir jetzt aber auf. Wenn ich das Fenster schliesse,
läuft das Programm noch weiter im Taskmanager.

MessageBox(NULL, "test", "test", MB_OK);
	return wmsg.wParam;
}

Habe vor return wmsg.wParam zur Fehleranalyse ne messagebox eingefügt.
Sie wird nicht ausgegeben. Die Fensterklasse wird korrekt zerstört
nach dem Schließen des Fensters aber die Schlefife geht noch weiter.
Ich kann nichts über die Rückgabe dieser Funktion reecharchieren bzw
wann sie mal false zurückgibt.

Die PostQuitMessage sendet dem Fenster die Nachricht WS_QUIT, dass
die Unendlich-Schleife beendet wird. Aber wozu ist der Parameter?
PostQuitMessage(0);

Ein Problem fällt mir jetzt aber auf. Wenn ich das Fenster schliesse, läuft das Programm noch weiter im Taskmanager.

Sobald das Hauptfenster WM_DESTROY verarbeitet hat, ist "hWnd" ungültig.
GetMessage () probiert dann die ganze Zeit, Botschaften für ein ungültiges Fensterhandle zu holen.
Das geht aber nicht, deshalb liefert GetMessage () ständig -1 zurück (schwerer fehler), was aber nirgendwo abgefragt wird.

MSG wmsg;
// while( GetMessage(&wmsg, hWnd, 0, 0) )
 while( GetMessage(&wmsg, 0, 0, 0) )      // <- besser so hier
 {
  ...
 }

sjBlack schrieb:

Die PostQuitMessage sendet dem Fenster die Nachricht WS_QUIT, dass die Unendlich-Schleife beendet wird.
Aber wozu ist der Parameter? PostQuitMessage(0);

PostQuitMessage () sorgt nur dafür, daß GetMessage () als Botschaft WM_QUIT holt woraufhin GetMessage () 0 (also FALSE) zurückgibt und die While-Schleife verlassen werden kann.
Der Parameter ist dann der Wert von "wmsg.wParam" den die Anwendung an das Betriebssystem zurückgibt.
Dieser Rückgabewert kann dann z.B. von einem anderen Programm via GetExitCodeProcess () abgefragt werden.

ah! und wozu ist die funktion CALLBACK LRESULT?
wofür steht überhaupt jetzt CALLBACK LRESULT?

Callback bezeichnet eine Rückruffunktion in der Informatik. Leicht verständliche Beispiele hier:

http://de.wikipedia.org/wiki/Rückruffunktion

wc.lpfnWndProc = WndProc;

Eine Kopie der Funktion reingesetzt wird, anstatt dass es so verstanden wird,
dass die Rückgabe der Funktion dem Strukturelement zugewiesen wird?

Dass der Compiler keien Fehelermeldung wirft, die Aktualparameterliste würde
fehlen, sondern die Kopie der Funktion zugewiesen wird und ohne
dieses Attribut ist es nicht möglich.

Spiele damit rum, damit ich aus dem Fensterprogramm auch wirklich alles verstehe:

#include <windows.h>

// Zum Empfangen und Auswerten der messages
LRESULT CALLBACK WndProc();

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
	struct test
	{
		LRESULT funktion;
		int aufrufe;
	} bla;

	bla.funktion = WndProc;

	while (int i = 0; i <= 4; i++)
	{
		bla.funktion();
		bla.aufrufe++;
	}

	return 0;
}

//
LRESULT CALLBACK WndProc()
{
	MessageBox(NULL, "Hallo", "hi", MB_OK);
}

Bekomme hier aber die Fehlermeldung

14 C:\Dokumente und Einstellungen\sjBlack\Desktop\Neuer Ordner (2)\main.cpp invalid conversion from `LRESULT (*)()' to `LRESULT'

Kennt jemand eine WinApi Datenbank, wo man Funktionen, structs und
Klassen von windows.h nachschlagen kann? Bräuchte ich mal dringend.
Das Recharchieren bei Google nach einzelnen Funktionen wird immer
aufwändiger.

Das deutsche Nachschlagewerk für Entwickler findet sich hier: http://msdn2.microsoft.com/de-de/library/default.aspx

Frage noch offen:

sjBlack schrieb:

Also ist CALLBACK ein Attribut, welches dafür sorgt, dass hier

wc.lpfnWndProc = WndProc;

Eine Kopie der Funktion reingesetzt wird, anstatt dass es so verstanden wird,
dass die Rückgabe der Funktion dem Strukturelement zugewiesen wird?

Dass der Compiler keien Fehelermeldung wirft, die Aktualparameterliste würde
fehlen, sondern die Kopie der Funktion zugewiesen wird und ohne
dieses Attribut ist es nicht möglich.

Spiele damit rum, damit ich aus dem Fensterprogramm auch wirklich alles verstehe:

#include <windows.h>

// Zum Empfangen und Auswerten der messages
LRESULT CALLBACK WndProc();

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
	struct test
	{
		LRESULT funktion;
		int aufrufe;
	} bla;

	bla.funktion = WndProc;

	while (int i = 0; i <= 4; i++)
	{
		bla.funktion();
		bla.aufrufe++;
	}

	return 0;
}

//
LRESULT CALLBACK WndProc()
{
	MessageBox(NULL, "Hallo", "hi", MB_OK);
}

Bekomme hier aber die Fehlermeldung

14 C:\Dokumente und Einstellungen\sjBlack\Desktop\Neuer Ordner (2)\main.cpp invalid conversion from `LRESULT (*)()' to `LRESULT'

please

// edit
Und noch eine Frage

case WM_CLOSE:
			DestroyWindow(hWnd);
		break;
		case WM_DESTROY:
			PostQuitMessage(0);
			return 0;

Kann man sich das nicht sparen mit:

case WM_CLOSE:
			DestroyWindow(hWnd);
			PostQuitMessage(0);
			return 0;

Kann man sich das nicht sparen mit:

case WM_CLOSE: 
            DestroyWindow(hWnd); 
            PostQuitMessage(0); 
            return 0;

Könnte man...
Aber ich sage mal: Nein. Das kann man nicht. Wenn Dein Fenster direkt durch DestroyWindow zerstört werden würde, dann wird kein PostQuitMessage ausgelöst.
Weil in diesem Moment WM_CLOSE nicht gesendet wird.

Besser und protabel (best practice) ist es einfach erst auf WM_DESTROY hin erst PostQuitMessage zu senden.

Holla.
Ich habe mich entschlossen, mir die Windows Api anzueignen,
da ich mich von Visual Basic komplett verabschieden will.
Die grundlagen von C++ kenne ich ja schon.

Bin schon mit dieser Seite dieses Tutorials durch:
http://pronix.linuxdelta.de/C/win32/win32_4.shtml

Ein Haufen Sachen sind für mich nicht nachvollziehbar.
Das meißte habe ich in diesem Turorial nur
heuristisch zum reinpasten gelernt

Das ist zum Lernen aber nicht unbedingt sinnvoll...

Zum Beispiel verstehe ich nicht, wieso man ein Fenster
bei Windows registriert mit einem struct, dass man
al Argument zum Registrieren übergibt und dann noch
das Fenster erstellt!?

Da gibt es nichts zu verstehen, es ist eben so. Ein Sinn liegt darin, daß der Fenstermanager überprüft, ob die Daten des registrierten Fensters gültig sind. Falls nicht, kann das Fenster nicht erstellt werden und er gibt "RegisterClassEx()" einen Fehlerwert zurück, den man analysieren kann. Ohne diese Prodzedur würde CreateWindowEx wohl Datensalat produzieren.

Jede 2e Zeile in diesem Tutorial heißt es "dafür schauen sie
bitte in der msdn nach", "dazu genauer unter der msdn" ich
meine, wenn man diese Andeutungen weglässt, hat man bloß noch
code zum pasten, jetzt mal im Ernst!

Internettutorials sind ein gutes Hilfsmittel zum Einstieg, reichen aber nicht aus, um sich eingehender damit zu befassen. Zum einen kannst Du Dir mehrere Tuts reinziehen, zum anderen gibt es dafür auch Bücher (Charles Petzold). Aber die meisten und umfangreichsten Infos gibt eben die MSDN. Man muß nur mit ihr umgehen können.

Aus einem msdn Artikel wurde ich in meinem ganzen Leben noch nicht schlau!
Ich schaffe es nicht einmal, per Google eine Erklärung
zum typedef LRESULT zu finden, wozu er a ist bzw. was er bringt.
Wieso LRESULT CALLBACK? Ist doch nur eine simple Funktion,
die durch wc ausgelöst wird.
Was bringt der MainClassName? Was bringt Translate Message?

LRESULT CALLBACK ist der Funktionstyp. Der ist in Windows.h definiert. Sowas steht im Petzold.
MainClassName ist nur der Name der Fensterklasse, der dem Strukturelement wc.lpszClassName zugewiesen wird. Wenn Du die C++-Grundlagen kannst, müßtest Du das eigentlich wissen.

Zu TranslateMessage:

Borland-Hilfe schrieb:

The TranslateMessage function translates virtual-key messages into character messages. The character messages are posted to the calling thread's message queue, to be read the next time the thread calls the GetMessage or PeekMessage function.

BOOL TranslateMessage(

CONST MSG *lpMsg // address of structure with message
);

Parameters

lpMsg

Points to an MSG structure that contains message information retrieved from the calling thread's message queue by using the GetMessage or PeekMessage function.

Return Values

If the message is translated (that is, a character message is posted to the thread's message queue), the return value is nonzero.
If the message is not translated (that is, a character message is not posted to the thread's message queue), the return value is zero.
Windows NT: The TranslateMessage function returns a nonzero value for function and arrow keys as well as for character and digit keys.

Remarks

The TranslateMessage function does not modify the message pointed to by the lpMsg parameter.
WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message.
TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver.

If applications process virtual-key messages for some other purpose, they should not call TranslateMessage. For instance, an application should not call TranslateMessage if the TranslateAccelerator function returns TRUE.

Die Fensterklasse ist eine Kathegorisierung, um bestimmte Attribute für alle Fenster dieser Klasse zu setzen (mit wc.cbClassExtra). Das nähert sich der OOP an.

Ich will zuerst mal einen simplen Texteditor coden.
Verdammt, ich weiß nichtmal, wie ich das Problem schildern soll!!!

// edit
Hab jetzt ne Runde recharchiert und kann das meißte jetzt nachvollziehen.
Ein Problem fällt mir jetzt aber auf. Wenn ich das Fenster schliesse,
läuft das Programm noch weiter im Taskmanager.

MessageBox(NULL, "test", "test", MB_OK);
	return wmsg.wParam;
}

Habe vor return wmsg.wParam zur Fehleranalyse ne messagebox eingefügt.
Sie wird nicht ausgegeben. Die Fensterklasse wird korrekt zerstört
nach dem Schließen des Fensters aber die Schlefife geht noch weiter.
Ich kann nichts über die Rückgabe dieser Funktion reecharchieren bzw
wann sie mal false zurückgibt.

Die PostQuitMessage sendet dem Fenster die Nachricht WS_QUIT, dass
die Unendlich-Schleife beendet wird. Aber wozu ist der Parameter?
PostQuitMessage(0);

PostQuitMessage teilt dem Fenster (und dem OS) mit, daß das Programm beendet wird und der dafür reservierte Speicher freigegeben werden kann. Auch das steht im Petzold.

Also ist CALLBACK ein Attribut, welches dafür sorgt, dass hier

wc.lpfnWndProc = WndProc;

Eine Kopie der Funktion reingesetzt wird, anstatt dass es so verstanden wird,
dass die Rückgabe der Funktion dem Strukturelement zugewiesen wird?

Einfach gesagt ist eine Callback-Funktion eine Funktion, die zwar im Quellcode vorhanden ist, aber nirgendwo aufgerufen wird.
Das mag ja verwirrend sein, daß man bei der WinAPI Funktionen schreiben muß, die man sowieso nicht aufruft.
Aber wenn Du via RegisterClassEx () eine selbstdefinierte Fensterklasse registrierst, dann braucht das Betriebssystem u.a. noch die Adresse einer bestimmten Funktion.
Diese Funktion wird immer dann aufgerufen wenn das Fenster eine Botschaft verarbeiten soll/muß.
Aufgerufen wird sie aber vom Betriebssystem. Deshalb Callback.
Als Callback-Funktion darf man allerdings keine x-beliebige Funktion schreiben.
Das Betriebssystem erwartet als Callback eine Funktion die folgende "Signatur" hat :

1       2                3          4          5              6
LRESULT CALLBACK WndProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam);

1   Rückgabetyp
2   Aufrufkonvention
2-6 Parameter (Argumente)

Mit "wc.lpfnWndProc = WndProc;" übergibt man dem Betriebssystem nur die Adresse der (selbstgeschriebenen) Callback-Funktion.

sjBlack schrieb:

Also ist CALLBACK ein Attribut, welches dafür sorgt, dass hier

wc.lpfnWndProc = WndProc;

Eine Kopie der Funktion reingesetzt wird, anstatt dass es so verstanden wird,
dass die Rückgabe der Funktion dem Strukturelement zugewiesen wird?

Einfach gesagt ist eine Callback-Funktion eine Funktion, die zwar im Quellcode vorhanden ist, aber nirgendwo aufgerufen wird.

Interessant. Wie soll ein Programm funktionieren, wenn LRESULT CALLBACK WndProc NIE aufgerufen wird?

Das mag ja verwirrend sein, daß man bei der WinAPI Funktionen schreiben muß, die man sowieso nicht aufruft.
Aber wenn Du via RegisterClassEx () eine selbstdefinierte Fensterklasse registrierst, dann braucht das Betriebssystem u.a. noch die Adresse einer bestimmten Funktion.
Diese Funktion wird immer dann aufgerufen wenn das Fenster eine Botschaft verarbeiten soll/muß.

ALLE Fensterklassen haben eine Funktion. Bei den vorregistrierten Fensterklassen (MessageBox, Button, Editfelder o.ä.) ist die Funktion schon von der API vorgegeben, bei selbsterstellten Klassen oder Dialogen muß man sie eben selbst schreiben.

Aufgerufen wird sie aber vom Betriebssystem.

Also doch..?

Deshalb Callback.
Als Callback-Funktion darf man allerdings keine x-beliebige Funktion schreiben.
Das Betriebssystem erwartet als Callback eine Funktion die folgende "Signatur" hat :

1       2                3          4          5              6
LRESULT CALLBACK WndProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam);

1   Rückgabetyp
2   Aufrufkonvention
2-6 Parameter (Argumente)

Mit "wc.lpfnWndProc = WndProc;" übergibt man dem Betriebssystem nur die Adresse der (selbstgeschriebenen) Callback-Funktion.

Ja, aber ist Callback jetzt ein Attribut?
Oder ist es ein typedef für einen pointer auf eine LRESULT Funktion?
Die Fensterstruktur verlangt ja doch eine Funktion als Referenz zw.
einen Pointer zu der Funktion, die als dessen Fensterprozedur
verwendet werden soll. Also nehme ich an, CALLBACK ist ein typedef
für einen pointer auf eine Funktion.

Ich möchte alles detailgenau wie möglich wissen.

Kannst du mir die URL zu Petzold pasten?

Ist keine URL, sondern eine ISBN:

http://www.amazon.de/Windows-Programmierung-m-CD-ROM-Charles-Petzold/dp/3860634879

Das Buch ist ja um ein Drittel billiger als vor 2 Jahren...

Ich will aber erst das meißte der WinApi beherrschen,
dann die MFC lernen und danach GUI.

Sehr vernünftig . Aber nur zur Klärung: GUI ist der Oberbegriff für "Graphical User Interface". Also ist die WinAPI ein GUI. wxWidgets, GTK, MFC u. a. sind objektorientierte Kapselungen der WinAPI, enthalten aber nicht die gesamte API, sondern nur die wichtigsten Funktionen. Oft genung muß man trotz MFC auf das "Rohprodukt" zurückgreifen. Also nicht irre machen lassen

#define CALLBACK    __stdcall

...und das gibt lediglich die Aufrufkonvention an.

In der winuser.h findet man noch:

typedef LRESULT (CALLBACK* WNDPROC)(HWND, UINT, WPARAM, LPARAM);

WNDPROC (zu finden als Member von WNDCLASS oder WNDCLASSEX) ist demnach nichts anderes als ein Zeiger auf eine Funktion vom Typ

LRESULT CALLBACK LustigerFunktionsname(HWND blupp, UINT bla, WPARAM bli, LPARAM blo)

Textfeld erzeugen:

HWND textWnd=CreateWindow("EDIT","blupp",WS_CHILD|WS_VISIBLE,10,10,200,20,HauptFensterHandle,NULL,hInstance,NULL);

...was die einzelnen Parameter einer WinAPI-Funktion sollen oder die Member einer Struktur kann man relativ gut in der msdn nachlesen.
Sehr zu empfehlen ist auch die Doku im "Platform SDK" oder "Windows SDK" - Und zwar deshalb weil man da über den Index sehr schnell Funktionen etc. nachschlagen kann und weil die msdn-online wie ich finde kacken lahm ist

http://www.microsoft.com/germany/msdn/library/windows/default.mspx?mfr=true
oder wenn ich hier nen Funktionsnamen eingebe, krieg ich
ein paar Links zu Artikeln anderer Seiten, die nichts
mit dem zutun haben, wonach ich suchte.

P.S.: Danke für die TextBox / EDIT

Windows Controls:
http://msdn2.microsoft.com/en-us/library/bb773173.aspx