100 Prozent Prozessorlast
-
In WM_PAINT nie! nur ein return 0; schreiben. Entweder gar nicht abfangen oder zumindest Begin- und EndPaint aufrufen
-
In habe gerde in der MSDN-Library noch etwas interessantes / wichtiges gelesen
Because the return value can be nonzero, zero, or -1, avoid code like this:
while (GetMessage( lpMsg, hWnd, 0, 0)) ...The possibility of a -1 return value means that such code can lead to fatal application errors. Instead, use code like this:
BOOL bRet; while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } }
-
und in WM_CREATE und WM_CLOSE hat ein einsames return 0; auch nix verloren...
-
case WM_KEYDOWN: switch (wParam) { case VK_ESCAPE: DestroyWindow(hwnd); break; default: break; }
-
RPD schrieb:
und in WM_CREATE und WM_CLOSE hat ein einsames return 0; auch nix verloren...
Macht zwar nicht viel Sinn, schadet imho aber auch nicht
Nur wenn du auf WM_CLOSE mit return 0; antwortest lässt sich das Fenster imho nicht mehr normal (X bzw. Alt+F4 oder Systemmenü) schließen
-
schaden ist relativ
return 0; hat imho außer in WM_PAINT und verwandten messages garnix verloren...
-
RPD schrieb:
return 0; hat imho außer in WM_PAINT und verwandten messages garnix verloren...
If an application processes this message, it should return zero [...]
Wieso steht das dann in der MSDN-Library bei (fast) allen Messages?
-
die haben einfach keine ahnung von switch-case-break
ernst:
ich weis auch das das in der msdn so steht aber warum?
sie sind sich ja selber net sicher obs sein muß siehe 'should'
-
Wenn du kein return 0 machst wird halt anschließend noch DefWindowProc aufgerufen (macht wohl meist wenig Sinn, wenn du die Nachricht schon bearbeitet hast)
-
flenders schrieb:
Macht zwar nicht viel Sinn, schadet imho aber auch nicht
ich glaub wir sind uns einig
-
das freut mich aber
-
-
warum so böse
