100 Prozent Prozessorlast
-
Willst du ein Spiel machen, oder warum hast du eine so seltsame (ist es für ein Spiel zwar immernoch) Main-Loop? So sieht die normalerweise aus:
while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); } return msg.wParam;Und das mit KEYDOWN(VK_ESCAPE)) macht man normalerweise mit WM_KEYDOWN in der WindowProc des Hauptfensters und DestroyWindow
Siehe auch: Gerüst für ein standard Windows-Programm
-
Ich hab das jetzt mal so gemacht. Aber die Prozessorauslastung ist immer noch bei 100 Prozent und dieses Sleep(0); hilft auch nicht.
-
Kann eigentlich fast nicht sein - zeig mal den ganzen Code (dürfte ja dann wohl noch nicht allzu viel sein)
-
Ok, hab eben schon gesucht wie ein Verrückter, aber nicht gefunden worans liegt.
Hier ist mal der gesamte Code:// defines #define WIN32_LEAN_AND_MEAN #define WINDOW_CLASS_NAME "WINCLASS1" #define KEYDOWN(vk_code) ((GetAsyncKeyState(vk_code) & 0x8000) ? 1 : 0) #define KEYUP(vk_code) ((GetAsyncKeyState(vk_code) & 0x8000) ? 0 : 1) // includes #include <windows.h> //#include <windowsx.h> // globals //################# Functions #################\\*/ LRESULT CALLBACK WindowProc (HWND, UINT, WPARAM, LPARAM); // WinMain int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE hprevinstance, LPSTR lpcmdline, int iCmdShow) { WNDCLASSEX winclass; // holds the window class HWND hwnd; // generic window handle MSG msg; // generic message // fill in fields of the window class winclass.cbSize = sizeof(WNDCLASSEX); // Save size of class winclass.style = CS_VREDRAW | CS_HREDRAW | CS_OWNDC | CS_DBLCLKS; // Redraw, Own Device Context, Send doubleclick message winclass.lpfnWndProc = WindowProc; // Callback - Function winclass.cbClsExtra = 0; // No extra information winclass.cbWndExtra = 0; // No extra information winclass.hInstance = hinstance; // assign the app instance winclass.hIcon = LoadIcon(hinstance, IDI_APPLICATION); // Load the icon of the window winclass.hCursor = LoadCursor(hinstance, IDC_ARROW); // Load the Cursor of the window winclass.hbrBackground = HBRUSH(GetStockObject(BLACK_BRUSH)); // Color for the Background winclass.lpszMenuName = NULL; // Name of the menu to attach winclass.lpszClassName = WINDOW_CLASS_NAME; // Name of the class itself winclass.hIconSm = LoadIcon(hinstance, IDI_APPLICATION); // Load the small icon of the window // Register window class if (!RegisterClassEx(&winclass)) return(0); // creates the window if(!(hwnd = CreateWindowEx (NULL, // extended style WINDOW_CLASS_NAME, // class "Muh", //title WS_OVERLAPPEDWINDOW | WS_VISIBLE, 300,200, // position 400,400, // size NULL, // handle to parent LoadMenu(hinstance, NULL), // handle to menu hinstance, // handle of this app NULL))) // extra creation parms return(0); ShowWindow (hwnd, iCmdShow); UpdateWindow (hwnd); // enter main event loop while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); } // return to windows return(msg.wParam); } // end WinMain // WinProc , main message handler LRESULT CALLBACK WindowProc(HWND hwnd, // window handle of sender UINT msg, // message id WPARAM wparam, // further defines messages LPARAM lparam) // further defines messages { // which message switch(msg) { case WM_CREATE: { // do initialization here return(0); } break; case WM_PAINT: { // begin painting return(0); } break; case WM_DESTROY: { // kills the app, this sends a WM_Quit message PostQuitMessage(0); return(0); } break; case WM_ACTIVATE: { if(LOWORD(wparam) != WA_INACTIVE) { // window is activated, do work } else { // window is deactivated, do work } } break; case WM_CLOSE: { // the window is being closed, do work return(0); } break; case WM_KEYDOWN: { if(KEYDOWN(VK_ESCAPE)) PostMessage(hwnd, WM_DESTROY, 0, 0); return(0); } break; default: break; } // end switch // default message handler (important!!!), process all other messages return(DefWindowProc(hwnd, msg, wparam, lparam)); } // end WinProcedit by flenders: Bitte Code-Tags verwenden!
-
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
