Es funktioniert einfach nicht
-
case WM_DESTROY: { PostQuitMessage(0); return (0); } break; default: return (DefWindowProc(hwnd,message,wparam,lparam)); }
-
Eure Antworten sind alle fürn A... . Schaut euch den Code doch mal richtig an. Das mit den breaks ist schon voll OK.
@<Newbie>: Wichtig ist es, den folgenden Code nach WM_CREATE zu verschieben:
memset(&lplfont,0,sizeof(lplfont)); lplfont.lfHeight = 13; lplfont.lfWidth = 3; lplfont.lfWeight = 320; lplfont.lfCharSet = ANSI_CHARSET; lplfont.lfPitchAndFamily = VARIABLE_PITCH | FF_SWISS; font = CreateFontIndirect(&lplfont); brush = CreateSolidBrush(RGB(255,0,0)); pen = CreatePen(PS_SOLID,1,RGB(0,255,0));
Sonst werden doch bei jedem Durchlauf der WindowProc (zig mal pro Sekunde) jeweils 1 neues Font, ein neuer Brush und ein neuer Pen erstellt. Das kann doch nur einen Überlauf erzeugen. Ach ja, und du solltest schon HFONT, HBRUSH bzw. HPEN als Typ angeben.
[ Dieser Beitrag wurde am 07.02.2003 um 22:19 Uhr von WebFritzi editiert. ]
-
Du hast auch recht.
Aber durch die breaks wird die DefWindowProc nie aufgerufen, deshalb werden viele Nachrichten nie bearbeitet und ständig neu gesendet. Deshalb die Prozessorauslastung von 100%.
[edit]Nein, du hast nichtmal ein bisschen recht! Das ist zwar nicht schön, da die Variablen aber nicht static sind, wäre dein Vorschlag fatal! Es ist doch erlaubt bei jedem Aufruf der WndProc diese Objekte neu zu erstellen (auch wenn es nicht schön ist, zugegeben).
[ Dieser Beitrag wurde am 08.02.2003 um 11:52 Uhr von Loggy editiert. ]
-
die message loop ist doch eine endlosschleife, bis man sie stoppt oder?
muß dann die auslastung nicht 100% betragen?
-
Das mit den break;s würde schon so funktionieren, allerdings müsste man, so wie ich das sehe das return (DefWindowProc(hwnd,message,wparam,lparam)); erst nach der schließenden Klammer von switch schreiben! Das break; verlässt ja nur den switch-Block.
100% Prozessorauslastung sind nicht normal
-
Eigentlich ja, wenn man solch eine Endlosschleife hat würde die Prozessorauslastung normalerweise 100 % betragen. Aber es gibt Befehle wie Sleep(0) die Rechenleistung wieder freigeben. Sowas is dann in GetMessage eingebaut
-
flenders: Jo, das wäre auch eine Möglichkeit.
Wollte gerade fragen, warum ein Compiler folgendes durchgehen lassen sollte:
switch (bla) { blub: { //blib }break; // <-- hier }
Da fiel mir ein, dass die { } hier ja völlig zusätzlich sind, also nicht unbedingt notwendig. Deshalb ist der blub Block erst beendet, wenn break kommt.
Trotzdem, an dem ursprünglichen Problem ändert es nichts.
-
Äh, ne!
Dein Programm hält in der GetMessage Funktion so lange an, bis eine neu Nachricht kommt. Wenn dein Programm also 10 min keine Nachricht bekommt, verbraucht es 10 min (fast) keine Prozessorlast.
Mit Sleep(0) kann man ähnliche Effekte erziehlen, jedoch sind die nicht so Wirkungsvoll, wie die der GetMessage Funktion.
-
1.) Du solltest entweder deine Font, Brush und Pen-Sachen einmal in WM_CREATE anlegen und dann ihre Variablen static machen oder einfach erst in WM_MOVE erzeugen
2.) Das wird wohl das Haupt-Problem sein: Du musst die Rückgabe-Werte von SelectObject speichern, und bevor du deine Objekte (font,bruch,pen) wieder löscht musst du diese wieder zurückselektieren (du kannst nichts löschen, was gerade in einen DC eingesetzt ist!). Also so in der Art:
HGDIOBJ hOldFont = SelectObject(hdc,font); HGDIOBJ hOldPen = SelectObject(hdc,pen); [...] // SelectObject liefert ja immer das Objekt zurück, was derzeit hineinselekiert ist - in dieser Art (font,brush,pen) DeleteObject( SelectObject(hdc,hOldPen) ); DeleteObject( SelectObject(hdc,hOldFont) ); // oder so: //SelectObject(hdc,hOldPen); //DeleteObject(hdc,pen); //SelectObject(hdc,hOldFont); //DeleteObject(hdc,font);
Das dürfte wohl der Fehler sein! :p
[ Dieser Beitrag wurde am 08.02.2003 um 13:54 Uhr von flenders editiert. ]
-
Hallo,
erst mal Danke für eure vielen Antworten. Ich hab jetzt alles ausgebessert und es funktionieeeeeeeertendlich. Ich hätte nicht gedacht das ich so viele Antworten kriege.
MFG Newbie