Programm blockiert ganz Windows

[stahli]

Einen Tipp habe ich nicht aber...

Ich kenne ein ähnliches Verhalten unter Win7 gelegentlich vom InternetExplorer bzw. beim öffnen mehrerer Register. Nach einigen Sekunden läuft es dann wieder.

Außerdem reagiert das System gelegentlich nicht mehr auf MouseOver und MouseClick (laufende Programme aber schon).
Es hilft dann der Affengriff und zwei Klicks auf abbrechen. Der erste bringt die Mauserkennung zurück, der zweite schließt die Systemebene.

[EWeiss]

Hier rumzurätzeln warum das so ist bringt einfach nichts.
Fakt ist jedoch wenn du anderen Prozessen nicht die möglichkeit gibst weiterarbeiten zu können
hält das System nun mal (scheinbar)an bis dein prozess beendet ist.
Das ist einfach ein schlechter Programmierstil.

Die lösung ist doch einfach.
Blockiere nicht die Prozesse anderer Awendungen und gut ist.
Kann ich nicht.. gibt es nicht.

Das hilft immer

Delphi-Quellcode:

procedure WinProcessMessages;
// Allow Windows to process other system messages
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;

Wer also will dir verbieten dafür zu sorgen das andere prozesse ihren Dienst verrichten können
FireBird ?

gruss

[Gruber_Hans_12345]

mir war das einfach absolut neu, das wenn ich in mienem Programm die Message nicht verarbeite das dann alle anderen Programme dadurch in mittleidenschaft gezogen werden.

Aber das Problem, ist trotzdem ich habe leider auch Komponenten von mir, die einfach sehr sehr lange zum verarbeiten brauchen (zum Beispiel PivotTabellen, die rieseige Datenmengen verarbetien) und da kann ich nicht einfach rumwerklen im sourcecode, und dort ne message loop einbauen.
Genau so schwer wird es sein das in nen Thread auszulagern, da diese Komponente natürlich auch grafisch ist ... und die GUI braucht (die ja nicht thread sicher ist)

[samso]

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

[Gruber_Hans_12345]

Zitat von samso:

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

Das muss ich morgen gleich mal probieren, ob es genau das verhalten ist, was ich bei meinem Programm auch festegestellt habe
Wie gesagt es sieht bei mir auch aus wie wenn "nur" der Desktop hängt

[EWeiss]

Zitat:

Das ist unmöglich. Es sei den du gibst deinen Prozess die höchste Priorität

Dann widersprichst du dir selbst!
Erst unmöglich und dann doch?

Na egal... sollte mich vielleicht etwas mehr zurückhalten.

gruss

[Jasocul]

Das passiert beim Open einer Query?
Dann mach davor doch davor ein DisableControls und danach ein EnableControls. Dazwischen vielleicht noch ein Application.ProcessMessages.

Ich kann mir nicht vorstellen, dass das Open den Rechner derartig ausbremst, aber die verbundenen Controls können schon einen ganze Menge verursachen.

[Luckie]

Zitat von EWeiss:

Zitat:

Das ist unmöglich. Es sei den du gibst deinen Prozess die höchste Priorität

Dann widersprichst du dir selbst!
Erst unmöglich und dann doch?

Wenn man nicht explizit an den Prioritäten dreht natürlich, das meinte ich mit dem Unmöglich.

[Gruber_Hans_12345]

Zitat von Gruber_Hans_12345:

Zitat von samso:

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

Das muss ich morgen gleich mal probieren, ob es genau das verhalten ist, was ich bei meinem Programm auch festegestellt habe
Wie gesagt es sieht bei mir auch aus wie wenn "nur" der Desktop hängt

Also das hätte ich gerade getestet, da hängts bei mir nicht, zumindest nicht in nem kleinen testprogramm nicht -> nur das Programm selbst natürlich, aber der Rest Desktop und co gehen noch

[Gruber_Hans_12345]

Also hab gerade ein kleines Testprogramm geschrieben, mit dem ich das ganze nachstellen wollte -> und siehe da
in dem Testprogramm bleibt der Desktop aktiv -> also keine Probleme, und nur mein kleines Testprogramm hängt

Also muss es irgendeinen nebeneffekt von meinem Hauptprogramm sein (Aber das sind leider schon doch ein paar zeilchen ... )