Hallo Delphifreunde!

Unter Windows 7 (ggf. auch schon unter Vista?!) können anscheinend laufende Programme (also die wirklich laufen und nicht nur auf Eingabe warten), die nicht kommunizieren (jedenfalls ist kein Application.Processmessages meinerseits implementiert) von außen unter- und gar abgebrochen werden. Mit "abgebrochen" meine ich nicht, daß das Programm beendet wird, sondern daß die interne Beschäftigung mit sich selbst anscheinend zum Erliegen kommt (obwohl die Prozessorauslastung laut Taskmanager nicht zurückgeht).

Das tritt z.B. auf, wenn man das Formular verschieben möchte - das ist bis Windows XP bei diesen Bedingungen unmöglich, da eben das Application.Processmessages fehlt. Windows 7 erlaubt es dennoch. Es tritt dann ein hellblaues "Rödelrad" auf, aber auch dann, wenn man z.B. zu einem anderen Formulare wechselt oder z.B. der Bildschirmschoner startet und man zum Formular des Rechenprogrammes zurückkehrt. Das Programm scheint manchmal noch weiter zu werkeln, ich hatte jedenfalls in diesem Zustande auch schon das Ende der Berechnungen. Besonders kritisch wird es anscheinend, wenn das Formular eingetrübt, eingenebelt wird - dann wird die interne Berechnung von außen abgebrochen(?) und läßt sich auch von außen nicht fortsetzen, jedenfalls ist ein Ende der Berechnungen dann nicht in Sicht.

Das ganze passiert - natürlich - mit einem eigenen Delphi-Compilat, und zwar reproduzierbar. Der Rödelkreis fiel mir zwar schon vorher auf, die Tragweite dessen, was sich dahinter abpsielt, jedoch erst vorhin.

Ist das unter Windows 7 normal (sicherlich), und kann man das Windows evtl. abgewöhnen (Einstellung?), oder schafft man es irgendwie, den unterbrochenen Programmablauf von außen forsetzen zu lassen?

Vielen Dank im voraus!

Gruß Delph-Laie

Das Verhalten ist bis XP exakt genauso was den Ablauf im betroffenen Programm angeht. Da wird weder dort noch ab Vista etwas abgebrochen.

Der Unterschied ist nur, dass Windows ab Vista den letzten Fensterinhalt noch zwischengespeichert hat und deshalb nicht mehr einfach gar nicht mehr aktualisiert (der Schliereneffekt bei nicht reagierenden Fenstern bis XP), sondern einfach ausgraut.

Wenn das bei deinem Programm reproduzierbar passiert, fehlt da wohl ein Thread für eine Berechnung.

Bei WIN 7 gibt es

Darstellung und Leistung von WINDOWS anpassen
Leistungsoptionen -> Datenausführungsverhinderung

Da kannst Du Dein Programm anmelden.
Es wird dann von der Datenausführungsverhinderung ignoriert.

Besser wäre es, das Programm SAUBER zu programmieren!
Was ist, wenn ein Programm Standby, Hibernate oder Shutdown aufruft?
Dein "beschissenes" Programm reagiert nicht!
Sowas würde bei mir gleich von der Platte fliegen!

In Windows 7 Laufen alle Fenster durch den Windows-Desktop-Manager, welcher für die Aero-typischen Darstellungen (diese milchige Transparenz und Co.) zuständig ist.
Wenn ein Programm/Fenster nicht mehr reagiert, dann wird ein screenshot davon gemacht, das Fenster auf dem Desktop ausgeblendet und stattdessen ein "Ersatzfenster" mit dem eingetrübten Foto angezeigt. (eingetrübt, damit man sieht, daß es hängt)

Das Ersatzfenster läßt sich nun verschieben, minimieren und Dergleichen, weil es nicht zum hängenden Prozess gehört, sonderm zum Desktopmanager.
Außerdem reagiert dieses Fenster auf den Schließenbutton oben rechts, wodurch dieses Programm dan abgeschossen wird, so als hätte man es über den Taskmanager beendet.
Das ist auch der Grund, warum bei häßlich geskinnten Programmen da urplötzlich die Windowstitelleiste auftaucht.



Also ich schließe mich an und rate zum ordentlichen Programmieren, wobei man also verhindert, daß das Programm hängen bleibt.

Zitat von hathor:

Bei WIN 7 gibt es

Darstellung und Leistung von WINDOWS anpassen
Leistungsoptionen -> Datenausführungsverhinderung

Das hat (mal wieder) nichts mit der Fragestellung zu tun.

Zur eigentlichen Frage hilft vielleicht dieser Artikel in dem das Verhalten von Windows dokumentiert ist: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
(hat himi schon angeschnitten, aber der Artikel geht noch etwas ins Detail...)
MfG

Danke für die Hinweise, vielleicht kann ich damit etwas bewerkstelligen.

Ich verbitte mir allerdings Verbalausfälle in bezug auf meine Programme/Programmierung. Application.Processmessages bläht den Code (sowohl Quell- als auch compilierten) auf und verlangsamt die Programmausführung, also die Ablaufgeschwindigkeit. Es hat also durchaus auch seine Berechtigung, das NICHT einzusetzen. Ein Programm sollte auch die Freiheit haben, ungestört werkeln zu dürfen. Daß neueres Windows damit nicht adäquat umgehen kann, ist in gewisser Weise Winzigweichs Schuld, denn Windows vorher machte auch nicht solche Anstalten darum. Auch wenn Windows das natürlich nicht unterschieden kann: Nicht jedes Programm, das die Kommunikation verweigert, "hängt" tatsächlich.

Sollte "hathor" sogar derselbe wie in der Entwickler-Ecke sein, wundert mich dieser sein "rauher Ton" (um es mal dezent auszudrücken) überhaupt nicht.

Es verbietet dir keiner, daß dein Code ohne ProcessMessages stundenlang laufen darf.
Aber dafür gibt es Threads.

Visuelle Oberflächen und vorallem der Hauptthread dürfen aber nunmal nicht einfach so nicht mehr auf den Benutzer reagieren, also hat Windows nun etwas drin, was dem Benutzer vor sowas wenigstens etwas beschützt.

Fazit: Es liegt an deinem Programm und nicht an Windows.

Wenn dein Programm nun mal nicht auf Nachrichten reagiert innerhalb von fünf Sekunden, dann geht Windows eben davon aus, dass es nicht mehr reagiert. Das kann eine Schleife sein, dass dein Programm nicht auf Windows nachrichten reagiert, das kann aber auch ein Funktionsaufruf sein, der nicht nach fünf Sekunden zurückkehrt. Und die Kritik an dein Programmkonzept scheint mir durchaus berechtigt. Aktionen, die länger dauern, lagert man nun mal in Threads aus, damit das Fenster eben noch reagiert. Und aufrufe von ProsessMessage blähen nicht das Programm auf. Dass es durchaus langsamer werden kann, wenn Nachrichten abgearbeitet werden müssen, ist hingegen richtig.

Zitat von Luckie:

Dass es durchaus langsamer werden kann, wenn Nachrichten abgearbeitet werden müssen, ist hingegen richtig.

Wobei es ja extrem bremst, wenn man dieses paar millionen (hunderte) Mal die Sekunde aufruft.
Aber es sagt ja keiner, daß man es mehr als 10 Mal die Sekunde aufrufen muß.

Zitat von Delphi-Laie:

...Winzigweichs...

Ich kanns nicht mehr hören. Ja, Du hast in Englisch aufgepasst.