Ich brauch hilfe und weis nicht weiter :/

Das return DefWindowProc(hWnd, message, wParam, lParam); ganz am Ende muss hinter die Klammer vom switch. Oder sehe ich das was falsch? Eigentlich dürfte das doch nicht einmal kompilieren, weil die Funktion nicht immer einen Wert zurückgibt, die Zeile würde höchstens ausgeführt werden, falls message == WM_DESTROY. Allerdings gibt es vorher ja schon ein anderes return.

phileman

So da bin ich nochmal ich hab jetzt das return DefWindowProc mal hinter die switch klammern gesetzt und jetzt geht es aber jetzt gibts n anders problem das fenster schlißt sich einfach so nach c.a. 1-2 sekunden

phileman schrieb:

So da bin ich nochmal ich hab jetzt das return DefWindowProc mal hinter die switch klammern gesetzt und jetzt geht es aber jetzt gibts n anders problem das fenster schlißt sich einfach so nach c.a. 1-2 sekunden

MSG msg;
    while ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) )
    {
        if (msg.message == WM_QUIT)
            break;

       TranslateMessage(&msg);
       DispatchMessage(&msg);        
    }

Probier mal das hier als Message Pumpe.

yahendrik

Scorcher24 schrieb:

MSG msg;
    while ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) )
    {
        if (msg.message == WM_QUIT)
            break;

       TranslateMessage(&msg);
       DispatchMessage(&msg);        
    }

Ohne es getestet zu haben: Ich denke nicht, dass dies funktioniert. PeekMessage liefert 0 zurück, wenn keine Nachricht mehr in der Queue ist, und dies ist nach recht kurzer Zeit das erste Mal der Fall.
Also entweder sowas wie

for(;;)
{
	while ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) )
	{
		if (msg.message == WM_QUIT)
			return msg.wParam;

		TranslateMessage(&msg);
		DispatchMessage(&msg);   
	} 	
}

, was die Prozessorlast natürlich unnötig in die Höhe treibt (okay, man könnte auch beim Peeken noch ein WaitMessage einbauen, dies würde aber PeekMessage ad absurdum führen), oder eben GetMessage, was für die meisten Anwendungen besser geeignet ist.

Ich sehe bei dem Code, sofern der Aufruf von DefWindowProc am Funktionsende steht, auch keinen Fehler. Hast du vielleicht einige Abfragen im switch-Block hinzugefügt und ein break/return vergessen, sodass der Code im WM_DESTROY-Zweig noch ausgeführt wird?

yahendrik schrieb:

Scorcher24 schrieb:
MSG msg;
    while ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) )
    {
        if (msg.message == WM_QUIT)
            break;

       TranslateMessage(&msg);
       DispatchMessage(&msg);        
    }
Ohne es getestet zu haben: Ich denke nicht, dass dies funktioniert. PeekMessage liefert 0 zurück, wenn keine Nachricht mehr in der Queue ist, und dies ist nach recht kurzer Zeit das erste Mal der Fall.
Also entweder sowas wie
for(;;)
{
	while ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) )
	{
		if (msg.message == WM_QUIT)
			return msg.wParam;

		TranslateMessage(&msg);
		DispatchMessage(&msg);   
	} 	
}
, was die Prozessorlast natürlich unnötig in die Höhe treibt (okay, man könnte auch beim Peeken noch ein WaitMessage einbauen, dies würde aber PeekMessage ad absurdum führen), oder eben GetMessage, was für die meisten Anwendungen besser geeignet ist.

Ich sehe bei dem Code, sofern der Aufruf von DefWindowProc am Funktionsende steht, auch keinen Fehler. Hast du vielleicht einige Abfragen im switch-Block hinzugefügt und ein break/return vergessen, sodass der Code im WM_DESTROY-Zweig noch ausgeführt wird?

Achso stimmt, ich führ das ja in einer anderen schleife noch aus >>.
Sorry mein Fehler.
Hab nicht dran gedacht >>.
Bin a bissl verplant heute scheinbar.

phileman

Also jetzt hab ichs ... ganz einfach ... Microsoft ist Dähmlich warum ? ... ganz einfach ich hab einfach nochnmal ein neues projekt angefangen ... und was passiert es geht ohne macken ich will ja nix sagen aber für welle die des lernen is das sicher netgeeignet xD

Aber ich möchte mich trozdem für eure hilfe bedanken

Der Fehler sitzt in 99% der Fälle zwischen Tastatur und Stuhllehne, d.h. 1% Warscheinlichkeit dass Microsoft dämlich ist, 99% Wahrscheinlichkeit, dass du dämlich bist.