Ich benutze Code::Blocks mit dem MinGW compiler, allerdings hab ich auch Dev-Cpp, visual c++ 6 und Visual C++ 2005 ausprobiert, immer mit dem gleichem erfolg.

Hier der quellcode:

#include <Windows.h>

const int REG_CLASS_ERR = 1;
const int CRE_WND_ERR = 2;
const int SHOW_WND_ERR = 3;
const int UPD_WND_ERR = 4;

// FUNCTION HEADER
LRESULT CALLBACK WndProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

// FUNCTIONS
int APIENTRY WinMain (HINSTANCE hInstance,
					HINSTANCE hPrevInstance,
					LPSTR lpCmdLine,
					int nCmdShow)

{
	MSG msg;
	WNDCLASSEX wndclass;
	HWND hwnd;

	char* szAppName = "simple_window";
	int start_x = 100;
	int start_y = 100;
	int height = 600;
	int width = 600;

	/* Filling wndclass Structure */
	wndclass.cbSize = sizeof (WNDCLASSEX);
	wndclass.style = CS_HREDRAW | CS_VREDRAW;
	wndclass.lpfnWndProc = WndProc;
    wndclass.cbClsExtra = 0;
	wndclass.cbWndExtra = 0;
	wndclass.hInstance = hInstance;
	wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
	wndclass.hCursor = LoadCursor (NULL, IDC_ARROW);
	wndclass.hbrBackground = (HBRUSH) GetStockObject (LTGRAY_BRUSH);
	wndclass.lpszMenuName = NULL;
	wndclass.lpszClassName = "simple_window";
	wndclass.hIconSm =  LoadIcon (NULL, IDI_APPLICATION);

	if (!RegisterClassEx (&wndclass) )
        {
                MessageBox (NULL, TEXT ("RegisterClassEx fehlgeschlagen!"),
                szAppName, MB_OK | MB_ICONERROR);
                return (REG_CLASS_ERR);
        }

	if (! (hwnd = CreateWindowEx(0,
						szAppName,
						"First Window",
						WS_OVERLAPPEDWINDOW | WS_VISIBLE,
						start_x, start_y,
						height, width,
						HWND_DESKTOP,
						NULL,
						hInstance,
						0) ))
            {
            MessageBox (NULL, TEXT ("CreateWindowEx fehlgeschlagen!"),
            szAppName, MB_OK | MB_ICONERROR);
            return (CRE_WND_ERR);
            }

	ShowWindow (hwnd, nCmdShow);
	UpdateWindow (hwnd);

	while ( GetMessage (&msg, hwnd, 0, 0) )
	{
		TranslateMessage (&msg);
		DispatchMessage (&msg);
	}

	return msg.wParam;

}

LRESULT CALLBACK WndProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
	switch (msg)
	{
	case WM_DESTROY:
		PostQuitMessage(0);
		break;
	default:
		DefWindowProc (hWnd, msg, wParam, lParam);
    }

    return 0;
}

Wer kann mir helfen, den Fehler zu finden?

LRESULT CALLBACK WndProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch (msg)
    {
        case WM_DESTROY:
            PostQuitMessage(0);
        break;
    }

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

vielleicht funzt es jetzt ja...

Mfg Ominion

So den Code ein wenig verbessert ^^ Und den Fehler rausgemacht ...

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);

statt

LRESULT CALLBACK WndProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

Mfg Ominion

Mfg Ominion

Ominion|off schrieb:

änder das mal Außerdem:

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);

statt

LRESULT CALLBACK WndProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

Gut mach, ich, nur... Warum? Ich meine bis jetzt hat es noch in allen Programmen funktioniert, und irgendwie empfinde ich die Lesbarkeit besser, wenn ich im Funktionskopf ein paar treffende Variablennamen finde.

Ominion|off schrieb:

Noch eine bitte: hört doch mal mit diesem unnützen casten auf! Das geht genauso gut ohne, und zu verstehen ist das ohne cast für nen Anfänger allemal besser...

Bezog sich das auf (D)Evil oder auf mich?
Also den Cast versteh ich schon, nur den sinn dahinter nicht, dass sollte doch bei der nächsten Übergabe sowieso per Standardkonvertierung umgewandelt werden, oder seh ich das falsch?

mfg, DrPhil_Guth

ps.: Ach ja, noch ne frage: Wieso findet man öfters anstatt einen Konstanten String anzugeben die Funktion TEXT() oder _T() wie (D)Evil sie hier angegeben hat? Was ist der vorteil dazu einen normalen Zeiger anzugeben?

Dann war das auf (D)Evil bezogen.
Aufgrund deiner Aussage, tippe ich mal darauf, dass du den cast meinst:

return static_cast<int>(msg.wParam);

Das ist sowieso Schwachsinn, da der einzige Unterschied zwischen int (was msg.wParam nach dem cast ist) und unsigned int (msg.wParam vor dem cast) der ist, dass int auch negative Zahlen beinhalten kann. Das heißt int hat ca. -1,70141·10³⁸ - 1,70141·10³⁸ den Bereich und unsigned int hat 3,40282·10³⁸ als Wertebereich und ist somit besser geeignet, wenn man mit sehr vielen Daten arbeitet, die nicht in den negativen Wertebereich reingehen.

Mfg Ominion

[EDIT]
Also _T () ist nur ein Makro von TEXT (""). TEXT ("") wandelt einen String in ANSCII um, und wird immermehr als guter Programmierstil angesehen
[/EDIT]

[EDIT]
Also _T () ist nur ein Makro von TEXT (""). TEXT ("") wandelt einen String in ANSCII um, und wird immermehr als guter Programmierstil angesehen
[/EDIT]

_T() ist genauso ein Makro wie TEXT(), und es wandelt nicht einen String in "ANSCII" um, sondern sorgt dafür, daß das angegebene Stringliteral je nach Kompilierung als String aus char (ANSI)- oder aus wchar_t (Unicode)-Zeichen angesehen wird.

Und zu gutem Programmierstil gehört IMHO eher, daß man derartige Strings nicht hartcodiert, sondern in Konfigurationsdateien auslagert, so daß sich die Anwendung mit wenig Aufwand lokalisieren läßt.

Mfg Ominion

Ominion schrieb:

In diesem Prototypen gibt man eigentlich immer nur den Typ der Daten ein, der dort ein kommen soll, und spezifiziert diese dann, wenn man die Funktion definiert.

Unsinn.

Das heißt int hat ca. -1,70141·10³⁸ - 1,70141·10³⁸ den Bereich und unsigned int hat 3,40282·10³⁸ als Wertebereich

Unsinn.

TEXT ("") wandelt einen String in ANSCII um,

Unsinn.

und wird immermehr als guter Programmierstil angesehen

Unsinn.

Das heißt int hat ca. -1,70141·1038 - 1,70141·1038 den Bereich und unsigned int hat 3,40282·1038 als Wertebereich und ist somit besser geeignet,

OMG !!

Ich glaube, du hast das falsche Tutorial erwischt xD Ne das stimmt so nicht.

Mfg Ominion

[EDIT] was ist daran falsch!? habe das aus mindestens 2 Quellen (also die Zahlen nicht, aber was den Unterschied zwischen unsigned und signed betrifft), wobei eine Quelle das sogar studiert haben will!
[/EDIT]

was ist daran falsch!? habe das aus mindestens 2 Quellen (also die Zahlen nicht, aber was den Unterschied zwischen unsigned und signed betrifft),

Die Zahlen sind falsch. Was du da als Wertebereich für unsigned int angibst, ist wohl eher der größte darstellbare Wert eines 32bit-Fließkommatypen. Und die gibt's nicht unsigned.

was ist daran falsch!?

Variablen des Typs int sind auf gebräuchlichen 32-Bit-Systemen 32 Bit breit. Der Wertebereich umfaßt also 2³² = 4294967296 verschiedene Zahlen. Bei unsigned int geht der Wertebereich folglich von 0 bis 4294967295, bei unsigned int von -2147483648 bis 2147483647.

Mfg Ominion

Gut, mal abgesehen von den Datentypen, was genau ist ANSCII ???

Vermutlich aus Halbwissen entstandener Unfug.

DrPhil_Guth schrieb:

Also Is klar, dass man strings lieber außerhalb lagern sollte, allerdings ist mir das für ein einfaches Hello World programm zu umständlich. Als ersatz schreib ich einfach die String- Literale irgendwo oben hin.

Klar, daß man das in einem Programm dieses Umfangs nicht macht. Ich schrieb das nur, weil jemand behauptete, solche Stringliterale im Code seien guter Programmierstil

DrPhil_Guth schrieb:

Ne allgemeine Frage: Wo kann finde ich denn eigentlich solche "Stilrichtlinien"?

Insbesondere durch Erfahrungen, die du während des Lesens und Bewertens diverser Dokumentationen und Bücher und der Quelltexte anderer gewinnst. Es gibt viele gute, aber unterschiedliche Stile, nur über Dinge, die man nicht tun sollte, herscht weitläufige Einigkeit. Deinen eigenen Stil mußt du freilich selbst finden.
Ein paar grundsätzliche Dinge, auf die du vielleicht achten solltest:
- vermeide globale Variablen
- kommentiere unübersichtliche Stellen eindeutig
- schreibe Funktionen reentrant
- gestalte dein Programm modular. Lagere Funktionalitäten in eigene Funktionen/Klassen/Module aus
- schreibe dein Programm, wo immer es sinnvoll sein kann, plattform- und compilerunabhängig
- wenn du die Wahl zwischen einer einfachen, unschönen und einer komplexeren, aber saubereren, erweiterbareren, abstrakteren Lösung hast, nimm letztere

Für C++-Programmierer noch ein paar weitere Ratschläge:
- vermeide Makros
- verwende die Standard-Library und die STL, wann immer es sinnvoll ist
- verstehe Zweck und Verwendung von Konzepten wie Polymorphie, generischer Programmierung, Template-Metaprogrammierung etc.
- entwirf mit diesen Kenntnissen für größere Projekte ein Klassenmodell, das einen erweiterbaren, flexiblen, objektorientierten Lösungsansatz darstellt
- lies Scott Meyers
- glaube niemals, C++ ganz verstanden zu haben

...

Insbesondere durch Erfahrungen, die du während des Lesens und Bewertens diverser Dokumentationen und Bücher und der Quelltexte anderer gewinnst. Es gibt viele gute, aber unterschiedliche Stile, nur über Dinge, die man nicht tun sollte, herscht weitläufige Einigkeit. Deinen eigenen Stil mußt du freilich selbst finden.
Ein paar grundsätzliche Dinge, auf die du vielleicht achten solltest:
- vermeide globale Variablen

Es lässt sicht oft nicht vermeiden. (1)

- vermeide Makros

(2)

- verwende die Standard-Library und die STL, wann immer es sinnvoll ist

- <vector> ist ein aufgeblähtes Ungetüm mit redundanter Funktionalität hoch 10.
Manchmal ist weniger mehr. (3)

- glaube niemals, C++ ganz verstanden zu haben
...

Uneingeschränkte Zustimmung

Nachsatz:
Alle Sprachmittel haben ihre Berechtigung, je nach Aufgabenstellung.
Das gilt speziell auch für globale Variablen und #defines.
Es ist nicht klug, sich selbst aus Prinzip den Einsatz von Sprachmitteln zu verbieten. Vielmehr sollte man immer alle Möglichkeiten ausschöpfen, die es gibt. Wer keine #defines haben will, kann auch Java verwenden.
mfg

DrPhil_Guth schrieb:

Gut, mal abgesehen von den Datentypen, was genau ist ANSCII ???

Vermutlich aus Halbwissen entstandener Unfug.

Tut mir leid, ich bin nur ein Mensch...ich werde mich in Zukunft nicht mehr verschreiben, damit der/die Herr/in mit mir in vollster Weise zufrieden ist

Mfg Ominion

Thx leute!

mfg, DrPhil_Guth

- vermeide globale Variablen

Es lässt sicht oft nicht vermeiden. (1)

Das kommt drauf an. Zumindest mit dem Windows-API läßt es sich praktisch immer vermeiden. Ausnahmefälle wie z.B. Shared Memory in DLLs natürlich außen vor gelassen.

Alle Sprachmittel haben ihre Berechtigung, je nach Aufgabenstellung.
Das gilt speziell auch für globale Variablen und #defines.

Nicht wenige, z.B. die hier genannten, haben ihre wesentliche Berechtigung in der Unterstützung von C.

Es ist nicht klug, sich selbst aus Prinzip den Einsatz von Sprachmitteln zu verbieten. Vielmehr sollte man immer alle Möglichkeiten ausschöpfen, die es gibt.

Klar. Aber was meinst du, warum von manchen Dingen gesagt wird, man solle sie nicht mehr verwenden? Weil es bessere Alternativen gibt!

Wer keine #defines haben will, kann auch Java verwenden.

Das war hoffentlich nicht ernst gemeint, oder? Sonst ziehe ich deine Fachkompetenz doch etwas in Zweifel.

Ominion schrieb:

Tut mir leid, ich bin nur ein Mensch...ich werde mich in Zukunft nicht mehr verschreiben, damit der/die Herr/in mit mir in vollster Weise zufrieden ist

Das mit dem Halbwissen bezog sich weniger auf den Schreibfehler. Ich meinte insbesondere diesen Satz, in dem du, deiner Sache offenbar sicher, meiner Vermutung nach aus besagtem Halbwissen erwachsenen Unfug behauptetest:

Ominion schrieb:

Also _T () ist nur ein Makro von TEXT (""). TEXT ("") wandelt einen String in ANSCII um, und wird immermehr als guter Programmierstil angesehen

Also _T () ist nur ein Makro von TEXT ("")

Hab jetzt nicht nachgeguckt ob dieser Irrtum schon beseitigt wurde... aber das stimmt so nicht. _T(x) ist ein eigenes Makro in tchar.h und macht von der Funktionalität zwar das selbe wie TEXT(x), ist aber nicht von diesem in irgendeiner Weise abhängig. Hab jetzt nicht nachgeguckt... aber _T(x) müsste höchstens von __T(x) abhängig sein

Danke euch beiden!
Jetzt Hab ich endlich wenigstens eine Rückgabe, und das fenster lässt sich auch schließen, nur den Prozess muss ich mit Strg - Alt - Entf beenden

while (GetMessage(&msg, NULL, 0, 0)) {/*...*/}

AFAIK.