Application.processmessages bremst Programm unter Windows 7 aus

[nahpets]

Eine Schleife mit permanentem ProcessMessage führt auch unter XP zu Verzögerungen, nur anscheinend nicht so massiv. Kenne das von Delphi 7.

Wenn ich so eine Schleife machen muss, dann kommt da immer auch ein Sleep rein, welche Wartezeit im Sleep steht, ist dann immer etwas von der zu erledigenden Aufgabe abhängig.

Wie bra schon schrieb, bitte mindestens in sowas der Art abändern:

Delphi-Quellcode:

procedure TLegacySerialProgrammerModule.ComPortAdapterSendChar(
  Sender: TObject; const Value: Char; const ContentType: TContentType);
begin
  while ComPort1.OutBuffUsed>0 do 
  begin
    // Hier prüfen, ob es ruhig etwas länger 
    // als 20 Millisekunden sein darf,
    // Tendenz eher in Richtung höher Wartezeit.
    Sleep(20); 
    application.ProcessMessages;
  end;
  if ComPort1.Open then
  begin
    ComPort1.PutChar(Value);
  end;
end;

Aus einem meiner Programme weiß ich, dass mit Delphi 7 unter XP eine Schleife mit einem Sleep unter 20 Millisekunden, auf 'nem recht alten Rechner, zu einem massiven Anstieg der CPU-Last führt, man beschäftigt so Windows ausschließlich mit der Verarbeitung der Messages. Aber ein sinnvolles aktives Warten kann man so nicht wirklich realisieren.

Optimal ist so eine Lösung nicht, aber zumindest mit 'nem überschaubaren Aufwand zu realisieren. Ihr müsstest aber gründlich testen, mit welcher Wartezeit ihr hier arbeiten könnt, damit keine anderen Nebenwirkungen auftreten.

[v2afrank]

Ja danke, hatte ich auch schon so verstanden. Problem ist aber dass es eher umgekehrt ist. Wenn ich ein Sleep dahin mache wird die Zeit auch unter XP deutlich höher. (Ob 7 kann ich jetzt nicht sagen da nicht getestet)
Vermutlich wird die Schleife bei beinahe jedem Zeichen angesprungen.
Interessant finde ich aber Deine Aussage dass Du das auch von Delphi 7 kennst.

[Glados]

Zitat:

Vielleicht könnte man statt oder zusätzlich zu dem Application.ProcessMessages noch ein Sleep(xx) (z.B. 100)

Dann würde bei der Übermittlung von nur 40 Buchstaben das Programm schon länger arbeiten, als es ohnehin schon unter Windows 7 tut

[Ydobon]

ProcessMessages räumt doch lediglich die Botschaftswarteschlange leer, damit die Anwendung während langer Schleifen nicht einfriert, was Sleep z.B. macht. Eine Verlängerung der Zeit sollte dann höchstens auftreten, wenn die Computerlast dadurch zu hoch und anderen Prozessen Zeit entzogen wird. Wenn es wirklich daran liegt, wäre HandleMessage vielleicht eine Idee oder eine Schleife ohne ProcessMessage, die aber vermutlich für hohe Last und weitere Probleme sorgen könnte.

Delphi-Quellcode:

while true do
begin
  if ComPort1.OutBuffUsed=0 then break;
end;

[freimatz]

Nu so ins Blaue: warum nicht "while ComPort1.OutBuffUsed>1 do"?
Dann kann der Buffer nicht überlaufen, aber es ist immer noch ein Zeichen in Reserve zum Schreiben noch da.

[v2afrank]

Der Schuss ins Blaue hat tatsächlich geholfen. Ich habe daraus ein >10 gemacht und jetzt funktioniert es auch unter 7.
Die Frage wäre natürlich was macht das Processmessages da wirklich unter 7. Aber ob man das herausfinden kann ?

Danke Euch allen erst einmal

[p80286]

Delphi-Quellcode:

procedure TLegacySerialProgrammerModule.ComPortAdapterSendChar(
   Sender: TObject; const Value: Char; const ContentType: TContentType);
begin
   while ComPort1.OutBuffUsed>0 do
       application.ProcessMessages;
   if ComPort1.Open then
   begin
     ComPort1.PutChar(Value);
   end;
end;

Das erinnert mich doch sehr an DOS-Zeiten

Delphi-Quellcode:

...
while BufferI<>Bufferlast do begin write('.') end;
writeln;
TuWas_mit_Buffer;
...

nur wird hier nichts ausgegeben, darum weißt Du nicht wieviel Zeit das Programm in der Warteschleife verbringt.

Übrigens, ist Value wirklich ein Char oder doch ein AnsiChar?

Gruß
K-H

[v2afrank]

Wirklich ein Char.
Bitte nicht vergessen. Das Programm ist gut 15 Jahre alt.

[p80286]

Zitat von v2afrank:

Wirklich ein Char.
Bitte nicht vergessen. Das Programm ist gut 15 Jahre alt.

Eben drum unter XE2 sollte der "alte" char dem AnsiChar entsprechen, und da ich davon ausgehe, daß es sich um binäre Daten handelt, wäre ein Byte wohl besser.

Gruß K-H