Schleifenabbruch durch Esc Taste...

[Codix32]

Hallo,

in der CodeLib auf Delphi Praxis gibt es die Beschreibung eines Schleifenabbruchs per Tastaturdruck
mit Messagedialog Abfrage:

http://www.delphipraxis.net/98300-sc...erbrechen.html

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
begin
   ResetEscPressed;
   for i := 0 to 10000000 do
   begin
     Caption := inttostr(i);
     if EscPressed('Schleife abbrechen ?') then Break;
   end;
end;

Beim Tastendruck wird das Hochzählen der Variablen i sofort gestoppt, aber der Messagedialog in der Funktion EscPressed wird erst 7 - 12 Sekunden später angezeigt.

Kann man da irgendwie was machen, dass der Dialog nahezu zeitgleich angezeigt wird?

[himitsu]

Zitat:

Zitat von Codix32 (Beitrag 1278365)

wird erst 7 - 12 Sekunden später angezeigt.

Entweder du machst was falsch, oder du hast den Code nicht ganz verstanden. :wink:

Zitat:

Zitat von Codix32 (Beitrag 1278365)

Kann man da irgendwie was machen, dass der Dialog nahezu zeitgleich angezeigt wird?

Ja, du drückst sofort ESC und somit kommt der Dialog auch sofort.

Und nicht die ESC-Taste zu lange drücken. :warn:


-> Wenn Taste gedrückt, dann zeige den Dialog an und frag nach, ob wirklich abgebrochen werden soll.

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1278370)

Zitat:

Zitat von Codix32 (Beitrag 1278365)

wird erst 7 - 12 Sekunden später angezeigt.

Entweder du machst was falsch, oder du hast den Code nicht ganz verstanden. :wink:

Zitat:

Zitat von Codix32 (Beitrag 1278365)

Kann man da irgendwie was machen, dass der Dialog nahezu zeitgleich angezeigt wird?

Ja, du drückst sofort ESC und somit kommt der Dialog auch sofort.

Und nicht die ESC-Taste zu lange drücken. :warn:


-> Wenn Taste gedrückt, dann zeige den Dialog an und frag nach, ob wirklich abgebrochen werden soll.

Was könnte da falsch sein?

Delphi-Quellcode:

Unit1

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
begin
  ResetEscPressed;
   for i := 0 to 10000000 do
    begin
     Caption := inttostr(i);
     if EscPressed('Schleife abbrechen ?') then break;
    end;
end;
...
...
...
unit Tastendruck;

interface

uses
  Windows, Dialogs, Controls;


function EscPressed(const Msg:string):Boolean;
procedure ResetEscPressed;

implementation


function EscPressed(const Msg:string):Boolean;
begin
   // Aus der WinAPI-Doku zu GetAsyncKeyState:
   // if the function succeeds, the return value specifies whether the key was pressed
   // since the last call to GetAsyncKeyState, and whether the key is currently up or down.
   // If the most significant bit is set, the key is down, and if the least significant bit is set,
   // the key was pressed after the previous call to GetAsyncKeyState.
   // The return value is zero if a window in another thread or process currently has the keyboard focus
   Result := ((GetAsyncKeyState(VK_ESCAPE) and $8001) <> 0) or
     ((GetAsyncKeyState(VK_PAUSE) and $8001) <> 0);
   if Result then
   begin
      Result := (MessageDlg(Msg, mtConfirmation, [mbYes,mbNo], 0) = mrYes);
   end;
end;

// muss vor dem Benutzen von EscPressed() aufgerufen werden
procedure ResetEscPressed;
begin
   GetAsyncKeyState(VK_ESCAPE);
   GetAsyncKeyState(VK_PAUSE);
end;

Also ich drücke den Button, die Schleife wird ausgeführt und im Form1.Caption wird das Hochzählen der Schleife angezeigt. Wenn ich jetzt ESC drücke, hört das Hochzählen sofort auf, aber der 'Schleife abbrechen' Dialog wird erst nach weiteren ~7 Sekunden angezeigt. Merkwürdig... Liegt es an Windows 7 64bit?
Während der 7 Sekunden geht am Rechner nichts anderes mehr.

[hathor]

Wenn man sowieso IMMER abbrechen will, kann man sich den Dialog sparen.

Delphi-Quellcode:

function EscPressed(const Msg:string):Boolean;
begin
   Result := ((GetAsyncKeyState(VK_ESCAPE) and $8001) <> 0) or
     ((GetAsyncKeyState(VK_PAUSE) and $8001) <> 0);
   if Result then Result := TRUE;
end;

[Codix32]

Zitat:

Zitat von hathor (Beitrag 1278376)

Wenn man sowieso IMMER abbrechen will, kann man sich den Dialog sparen.

Delphi-Quellcode:

function EscPressed(const Msg:string):Boolean;
begin
   Result := ((GetAsyncKeyState(VK_ESCAPE) and $8001) <> 0) or
     ((GetAsyncKeyState(VK_PAUSE) and $8001) <> 0);
   if Result then Result := TRUE;
end;

Das Stimmt. Aber jetzt habe ich das Problem, dass nach dem Klick auf Escape die Schleife zwar gebreakt wird, aber wenn ich versuche, das Formular zu schliesen, dauert das gut 7 Sekunden. Das Programm scheint einzufrieren.

[Luckie]

Klingt so, als wenn im Hintergrund die Schleife noch laufen und das Formular blockieren würde. Entweder man ruft in der Schleife Application.ProcessMessages auf oder man lagert das alles in einen Thread au.

[Codix32]

Zitat:

Zitat von Luckie (Beitrag 1278383)

Klingt so, als wenn im Hintergrund die Schleife noch laufen und das Formular blockieren würde. Entweder man ruft in der Schleife Application.ProcessMessages auf oder man lagert das alles in einen Thread au.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
begin
  ResetEscPressed;
   for i := 0 to 10000000 do
    begin
     Application.ProcessMessages;
     Caption := inttostr(i);
     if EscPressed('Schleife abbrechen ?') then break;
    end; //For
    Label1.Caption:= 'stop';
end; //proc

Application.ProcessMessages bringt keine Änderung.

Beim Klick auf ESC zeigt das Label sofort 'Stop' an, die Schleife wird also sofort verlassen.
Es muss einen anderen Grund geben. Gibt es eine andere Möglichkeit als GetAsyncKeyState?

[Dalai]

Keine Ahnung, was bei dir los ist, aber bei mir funktioniert dein Code. Ich würde in jedem Fall in die Schleife ein Sleep einbauen, damit andere Threads und Prozesse Zeit bekommen und dein Thread nicht die CPU voll auslastet. Ein

Delphi-Quellcode:

Sleep(1);

reicht da schon aus. Warum überhaupt eine for-Schleife mit einem hohen Zahlenwert als Abbruchbedingung statt einer while- oder repeat-until-Schleife?

MfG Dalai

[Codix32]

Zitat:

Zitat von Dalai (Beitrag 1278439)

Keine Ahnung, was bei dir los ist, aber bei mir funktioniert dein Code. Ich würde in jedem Fall in die Schleife ein Sleep einbauen, damit andere Threads und Prozesse Zeit bekommen und dein Thread nicht die CPU voll auslastet. Ein

Delphi-Quellcode:

Sleep(1);

reicht da schon aus. Warum überhaupt eine for-Schleife mit einem hohen Zahlenwert als Abbruchbedingung statt einer while- oder repeat-until-Schleife?

MfG Dalai

Vielen lieben Dank Dalai,

das Sleep(1) sorgt tatsächlich dafür, dass ich nach dem Klick auf ESC das Formular schließen kann.

Ich habe das Sleep einfach mal so eingefügt:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
begin
  ResetEscPressed;
   for i := 0 to 10000000 do
    begin
     Application.ProcessMessages;
     Caption := inttostr(i);
     Sleep(1);                    //<- Sleep in der Schleife
     if EscPressed('Schleife abbrechen ?') then break;
    end; //For
    Label1.Caption:= 'stop';
    Application.ProcessMessages;
    Button1.Enabled:=false;
end; //proc

Was ich gern verstehen würde, warum das so funktioniert, denn:

Denn auch ohne Sleep zeigt das Label1 sofort 'Stop' an,wenn ich ESC drücke, das heißt doch, dass die Schleife auch verlassen ist. Warum brauche ich jetzt das Sleep um das Form schließen zu können? Was passiert da noch im Hintergrund? Und ich wäre jetzt nicht darauf gekommen da ein Sleep einzubauen.
Und warum nun eine 4Kern CPU von einer Form.exe total eingenommen wird, wenn da
ein GetAsyncKeyState(VK_ESCAPE) in einer Schleife drin ist, verstehe ich ebenfalls nicht.

[Dalai]

Ganz einfach: das Sleep erlaubt, anderen Prozessen und Threads zu arbeiten. Ohne das Sleep geht die Schleife so schnell durch, wie es dein Prozessor erlaubt - und "blockiert" damit auch den Thread, der sich um die GUI kümmert. Übrigens wird nur ein Kern ausgelastet, nicht mehr - ist ja nur ein Thread und ein Thread kann gleichzeitig nur auf einem Kern laufen.

MfG Dalai

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1278854)

Übrigens wird nur ein Kern ausgelastet, nicht mehr - ist ja nur ein Thread und ein Thread kann gleichzeitig nur auf einem Kern laufen.

Da windows die Prozesse nicht an einen Kern bindet, und die sowieso ständig in und aus den Kernen schiebt (es gibt ja mehr Threads als Kerne), kann es passieren, daß Windows den Prozess auch in mehreren Kernen laufen lässt. Natürlich nicht gleichzeitig, sondern nacheinander, so daß in der Gesamtrechnung ein Thread dennoch nicht mehr als einen Thread auslastet.

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

[hathor]

Zitat:

Zitat von himitsu (Beitrag 1278989)

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

Du reihst Dich ein bei den Urhebern dummer Sprüche:
„Ich glaube, dass es auf der Welt einen Bedarf von vielleicht fünf Computern geben wird.“
http://de.wikipedia.org/wiki/Thomas_J._Watson

[himitsu]

16 Kerne für einen Office+Internet-PC sind also besser als 8?

[DeddyH]

Natürlich, wenn 15 Kerne vor sich hinschlummern statt nur 7, ist das doch viel cooler.

[Jumpy]

Zitat:

Zitat von DeddyH (Beitrag 1279015)

Natürlich, wenn 15 Kerne vor sich hinschlummern statt nur 7, ist das doch viel cooler.

Es sei denn es kommt zur Kernschmelze, dann ist es natürlich viel hotter. :-D

Tschuldijung, Freitag eben...

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1278989)

Zitat:

Zitat von Dalai (Beitrag 1278854)

Übrigens wird nur ein Kern ausgelastet, nicht mehr - ist ja nur ein Thread und ein Thread kann gleichzeitig nur auf einem Kern laufen.

Da windows die Prozesse nicht an einen Kern bindet, und die sowieso ständig in und aus den Kernen schiebt (es gibt ja mehr Threads als Kerne), kann es passieren, daß Windows den Prozess auch in mehreren Kernen laufen lässt. Natürlich nicht gleichzeitig, sondern nacheinander, so daß in der Gesamtrechnung ein Thread dennoch nicht mehr als einen Thread auslastet.

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

Ja ok, es laufen Prozesse, die man nochmal in Threads unterteilen kann, oder so ähnlich.
Aber die werden ja großteils blockiert, wenn ich die Schleife ohne Sleep laufen lasse.
Es geht dann eben 12 Sekunden lang nichts mehr. Weder in der compilierten Form, noch lässt sich ein anderes externes Fenster anklicken. Der Mauszeiger bleibt solange der Pfeilzeiger.

[BUG]

Eigendlich sollte kein Thread in der Lage sein, irgendeinen anderen durch eine Schleife zu "blockieren" (abgesehen von welchen mit niedriger Priorität). Dafür sorgt das Betriebssystem.
Deswegen finde ich auch die Lösung mit dem Sleep irgendwie merkwürdig (und die Erklärung dazu) :gruebel:

[himitsu]

Jeder Thread bekommt vom System ein "Fenster" von paar Millisekunden, in dem es einen Kern nutzen kann, bevor Windows den Kern für den nächsten Thread freimacht.
Mit einem Sleep(0) kann man sein "Fenster" sofort abbrechen ... damit Windows nicht "sinnlos" den Thread weiter behandelt, obwohl er "jetzt" nichts mehr machen will.


Was ist das denn für ein PC?
Wieviele Kerne gibt es und wie sind die ausgelastet? (während der Schleife und in den 12 Sekunden, bzw. davor/danach)
Wie sieht der RAM aus? (im Cache, Verfügbar, Frei, Ausgelagert und Zugesichert)

Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

[Dejan Vu]

Zitat:

Zitat von BUG (Beitrag 1279038)

Eigendlich sollte kein Thread in der Lage sein, irgendeinen anderen durch eine Schleife zu "blockieren" (abgesehen von welchen mit niedriger Priorität). Dafür sorgt das Betriebssystem.

Soweit ich mich erinnere, muss der Thread schon selber Bescheid geben, wenn er unterbrochen werden könnte, meist durch API-Aufrufe. Eine Endlosschleife ohne Sleep wird nie Bescheid geben, das jemand Anderes auch mal ran darf, zumindest ein Kern ist dann ausgelastet. Hier sollte jedoch ein Sleep(0) auch reichen. Immerhin könnte es ein, das Sleep(1) 18ms lang wartet, weiß ich jetzt aber nicht mehr so genau.

Zitat:

Zitat von himitsu (Beitrag 1279041)

Jeder Thread bekommt vom System ein "Fenster" von paar Millisekunden, in dem es einen Kern nutzen kann, bevor Windows den Kern für den nächsten Thread freimacht....Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

Wie passt das zusammen? Also entweder habe ich einen Scheduler, der per Interrupt den Thread unterbricht, dann kann ein Thread nix lahmlegen, oder ich habe einen Scheduler, der nur Prozesse unterbricht, aber keine Threads. Dann kann der Thread den Prozess lahmlegen.

Soweit ich weiß, unterbricht Windows die Threads nicht selbst, sondern nur die Prozesse...

[Dalai]

Wie ich schon schrieb, gibt es das Problem mit der Verzögerung auf den Abbruch bei mir auch nicht ohne Sleep. Ich hab das Sleep nur eingesetzt, um die sinnlose Auslastung der CPU zu unterbinden, weil die Schleife ohne Sleep eben so schnell durchrauscht, wie es die CPU hergibt. Mit Sleep wird die Schleife für einige Millisekunden unterbrochen und dann läuft die Schleife auch merklich langsamer durch. Ein Sleep(0) lastet übrigens genauso aus wie ohne Sleep.

Der Nebeneffekt des Sleep ist, dass auch andere Threads desselben Prozesses Zeit bekommen, auch wenn sie das aufgrund des Schedulers eigentlich sowieso müssten, vor allem bei Mehrkernern. Daher weiß ich nicht genau, warum das Sleep beim Verzögerungsproblem hilft. Ich vermute, dass der GUI-Thread derselbe ist wie der der Schleife - und da der mit der Schleife zu tun hat, kommt er nicht mehr zum Bearbeiten der GUI.

MfG Dalai

[p80286]

Und wie wäre es mit einem

Delphi-Quellcode:

application.processmessages

?

Gruß
K-H

[Dejan Vu]

Ich meinte nur:
Sleep(0) - Threadwechsel
Sleep(1...9999) - Warten und Threadwechsel

Dann habe ich deine Intention von 'Sleep(1)' verstanden...

[Dalai]

Zitat:

Zitat von p80286 (Beitrag 1279046)

Und wie wäre es mit einem

Delphi-Quellcode:

application.processmessages

?

Das steht ja bereits drin, hilft aber laut Aussage des OP nichts. Unabhängig davon entgegnet das nicht der Auslastung, aber es sollte die Verzögerung beheben, was es bei mir auch tut.

MfG Dalai

[BUG]

Zitat:

Zitat von Dejan Vu (Beitrag 1279042)

Soweit ich mich erinnere, muss der Thread schon selber Bescheid geben, wenn er unterbrochen werden könnte, meist durch API-Aufrufe.

Definitiv nicht. Sleep gibt den Prozessor freiwillig ab, blockierende Systemaufrufe auch. Ansonsten sind Threads präemptiv, dh. dem Thread wird die CPU entrissen wann immer das Betriebsystem Lust dazu hat.

Zitat:

Zitat von himitsu (Beitrag 1279041)

Dann kann der Thread den Prozess lahmlegen. [...] Soweit ich weiß, unterbricht Windows die Threads nicht selbst, sondern nur die Prozesse...

Man unterscheidet User-Level-Threads und System-Level-Threads. Von User-Level-Threads hat das System keine Ahnung und sie laufen nicht parallel. Unter Windows könnten das Fibers (sind eher Coroutinen) sein, man könnte es auch selbst implementieren. System-Level-Threads sind dem System bekannt und können echt parallel laufen. Die normalen Threads, die man in der Regel benutzt, sind System-Level-Threads.

Zitat:

Zitat von Dalai (Beitrag 1279045)

Ich vermute, dass der GUI-Thread derselbe ist wie der der Schleife - und da der mit der Schleife zu tun hat, kommt er nicht mehr zum Bearbeiten der GUI.

Ich auch ... schon weil das in einem Ereignishandler läuft, der vermutlich vom Mainthread aufgerufen wird. Dann sollte ProzessMessages aber ausreichen, da es der GUI nicht helfen sollte, wenn der Thread die Kontrolle abgibt.


Deswegen: Irgendwas läuft da verkehrt :gruebel:

[Blup]

Delphi-Quellcode:

{...}
Caption := inttostr(i);
{...}

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?
Da wird nicht nur ein Feld in der VCL-Klasse verändert.

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1279041)

...
Was ist das denn für ein PC?
Wieviele Kerne gibt es und wie sind die ausgelastet? (während der Schleife und in den 12 Sekunden, bzw. davor/danach)
Wie sieht der RAM aus? (im Cache, Verfügbar, Frei, Ausgelagert und Zugesichert)

Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

• Acer Predator G3610
  8 GB RAM
  64 Bit - Betriebssystem
  Prozessorkerne 4
  Grafik AMD Radeon HD 6870

Du wirst es vielleicht nicht glauben, aber wenn ich den Task Manager aufrufe und die Leistung anzeige, bleibt selbst die Grafik stehen, die sonst im Sekunden Rhythmus von rechts nach links läuft. Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?
Im Ressourcenmonitor bleibt die Grafik nicht hängen und die Kerne 0, 2 und 4 schlagen aus.

Ups. Im 2. Versuch bleibr auch der Resourcenmonitor kurz stehen, zeigt dann aber Ausschläge bis fast 100% bei Kernen 2, 4 und 6 an.

[BUG]

Zitat:

Zitat von Blup (Beitrag 1279092)

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet :shock:
Das könnte schon ein bisschen Ärger machen.

Zitat:

Zitat von Codix32 (Beitrag 1279096)

Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?

Wahrscheinlich Hyperthreading: Jeder echte Kern stellt 2 Hardware-Threads bereit. Die werden nicht echt gleichzeitig ausgeführt, können aber Wartezeiten im Prozessor überbrücken.

[Codix32]

Zitat:

Zitat von BUG (Beitrag 1279100)

Zitat:

Zitat von Blup (Beitrag 1279092)

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet :shock:
Das könnte schon ein bisschen Ärger machen.

Zitat:

Zitat von Codix32 (Beitrag 1279096)

Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?

Wahrscheinlich Hyperthreading: Jeder echte Kern stellt 2 Hardware-Threads bereit. Die werden nicht echt gleichzeitig ausgeführt, können aber Wartezeiten im Prozessor überbrücken.

Wie kann ich das prüfen, ob es das Form1.caption ist?
Wenn ich das Caption auskommentiere läuft die Schleife zu schnell ab. Vielleicht eine zweite Schleife rein? Mal sehen.

[BUG]

Zitat:

Zitat von Codix32 (Beitrag 1279104)

Vielleicht eine zweite Schleife rein? Mal sehen.

Entweder das, oder:

Zitat:

Zitat von Dalai (Beitrag 1278439)

Warum überhaupt eine for-Schleife mit einem hohen Zahlenwert als Abbruchbedingung statt einer while- oder repeat-until-Schleife?

[himitsu]

Zitat:

Zitat von BUG (Beitrag 1279100)

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet :shock:
Das könnte schon ein bisschen Ärger machen.

Und keiner gibt dem MainThread Zeit diese zu verarbeiten.

Das passiert alles erst nach dem Ende der Methode, bzw. beim Anzeigen des Abbruch-Dialogs.

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1279109)

Und keiner gibt dem MainThread Zeit diese zu verarbeiten.

Sicher? Das doch macht Application.ProcessMessages.

[Codix32]

Zitat:

Zitat von BUG (Beitrag 1279108)

Zitat:

Zitat von Codix32 (Beitrag 1279104)

Vielleicht eine zweite Schleife rein? Mal sehen.

Entweder das, oder:

Zitat:

Zitat von Dalai (Beitrag 1278439)

Warum überhaupt eine for-Schleife mit einem hohen Zahlenwert als Abbruchbedingung statt einer while- oder repeat-until-Schleife?

Du meinst eine Endlossschleife? Ja, das stimmt eigentlich. Ok

[Codix32]

Zitat:

Zitat von Codix32 (Beitrag 1279117)

Zitat:

Zitat von BUG (Beitrag 1279108)

Zitat:

Zitat von Codix32 (Beitrag 1279104)

Vielleicht eine zweite Schleife rein? Mal sehen.

Entweder das, oder:

Zitat:

Zitat von Dalai (Beitrag 1278439)

Warum überhaupt eine for-Schleife mit einem hohen Zahlenwert als Abbruchbedingung statt einer while- oder repeat-until-Schleife?

Du meinst eine Endlossschleife? Ja, das stimmt eigentlich. Ok

Dalai, danke,

Wenn ich das Caption rauslasse kann ich ESC drücken und das Form sofort schließen.

Delphi-Quellcode:

procedure TForm1.EndlossSchleife;
 var
 i:integer;
begin
 ResetEscPressed;
 while i <= 100000000 do
  begin
       Application.ProcessMessages;
       if EscPressed('Schleife abbrechen ?') then break;
  end;
      Label1.Caption:= 'stop';
end;

Wenn ich jetzt ein 'Caption:=inttostr(i);' einfüge, kann ich auch das Form sofort schliesen.
Erst wenn ich jetzt ein 'inc(i)' reintue, habe ich wieder das Problem

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1279109)

Zitat:

Zitat von BUG (Beitrag 1279100)

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet :shock:
Das könnte schon ein bisschen Ärger machen.

Und keiner gibt dem MainThread Zeit diese zu verarbeiten.

Das passiert alles erst nach dem Ende der Methode, bzw. beim Anzeigen des Abbruch-Dialogs.

@himitsu,

Das Caption ist aber schon zum Zähler geworden, nachdem ich den Button angeklickt habe und hat auch beim Drücken der ESC Taste sofort gestoppt.

[hathor]

Das procedure TForm1.EndlossSchleife; scheint nicht das Einzige zu sein, was in Deinem Programm abläuft.
Wie wäre es mit dem vollständigen Code...?

[himitsu]

Zitat:

Zitat von BUG (Beitrag 1279112)

Zitat:

Zitat von himitsu (Beitrag 1279109)

Und keiner gibt dem MainThread Zeit diese zu verarbeiten.

Sicher? Das doch macht Application.ProcessMessages.

Zitat:

Zitat von Codix32 (Beitrag 1278365)

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
begin
   ResetEscPressed;
   for i := 0 to 10000000 do
   begin
     Caption := inttostr(i);
     if EscPressed('Schleife abbrechen ?') then Break;
   end;
end;

Wo?
Also zumindestens nicht im Original. :stupid:


Die Frage ist auch, ob man hier wirklich eine Lösung braucht, oder man man nicht besser einen "ordentlichen" und vorallem praxisnaheren Code verwendet.

[BUG]

Zitat:

Zitat von Codix32 (Beitrag 1279120)

Wenn ich jetzt ein 'Caption:=inttostr(i);' einfüge, kann ich auch das Form sofort schliesen.
Erst wenn ich jetzt ein 'inc(i)' reintue, habe ich wieder das Problem

Ich vermute mal, das da auf Gleichheit geprüft wird, bevor irgendetwas bewegendes passiert. Müsste man wohl in die Sourcen gucken.

Allerdings hat Himitsu schon recht: richtig bringt es nichts, dem jetzt nachzuspüren ... hast du denn noch Problem mit dem Code in deiner Anwendung?

[Luckie]

Zitat:

Zitat von Dejan Vu (Beitrag 1279042)

Soweit ich mich erinnere, muss der Thread schon selber Bescheid geben, wenn er unterbrochen werden könnte, meist durch API-Aufrufe.

Du erinnerst dich falsch. jeder laufende Thread bekommt eine Zeitscheibe. Höher priorisierte Threads kommen einfach öfters dran und nicht länger.

Zitat:

Soweit ich weiß, unterbricht Windows die Threads nicht selbst, sondern nur die Prozesse...

Auch das stimmt leider nicht. Ein Prozess ist nur ein "Container" für Windows zur Verwaltung. Code wird immer nur von Threads ausgeführt.

[hathor]

Seit WIN VISTA gibt es neue APIs, u.a. die wait chain traversal API.
http://msdn.microsoft.com/de-DE/libr...=vs.85%29.aspx
http://docwiki.embarcadero.com/RADSt.../de/Wait_Chain

Man kann im Task Manager mit Rechtsklick auf das verdächtige Programm sehen, ob Threads hängen - siehe Anhang.

[Codix32]

[QUOTE=BUG;1279134]

Zitat:

Zitat von Codix32 (Beitrag 1279120)

...
Allerdings hat Himitsu schon recht: richtig bringt es nichts, dem jetzt nachzuspüren ... hast du denn noch Problem mit dem Code in deiner Anwendung?

Nö, BUG,

es ist wirklich so, dass ich in dieser Anwendung nur diese Schleife laufen ließ, um den Tatenabbruch zu testen, es ist da sonst nichts.

Ich wollte jetzt auch nicht unbedingt eine Lawine lostreten. Es genügt mir, dass ich mit 'Sleep' ein Aufhängen des Rechners verhindern kann.
Natürlich mache ich mir schon Gedanken, dass eine 'GetAsyncKeyState' einen solchen programmübergreifenden Hänger verursachen kann. Sehe gerade, dass die Funktion der WinApi angehört, also keine, nur Delphi interne Funktion ist.
Andererseits habe ich auch schon an Net Framework 1.1 gedacht, das installiert sein muss, um Delphi 2005 überhaupt installieren zu können.