Programm blockiert ganz Windows

[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.

[Gruber_Hans_12345]

Zitat von 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.

nein, es sind gar keine Controls verbunden, das ist nur eine Query die eine PivotTabelle befüllt
aber braucht dafür natürlich sehr lange zum öffnen ...

[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.

[EWeiss]

Habe solche probleme schon des öfteren feststellen müssen..
Nach einem Neustart des Systems blockiert beim ersten start von D2010 die initialisierung
das komplette System keine Maus der irgendwelche eingaben sind dann noch möglich.
Behoben wurde das mit dem IDEFix irgendwo von hier.

Beim ersten Start von Adobe Photoshop lastet die suche nach den Fonts
auch das komplette system aus selbe problem wie oben.

Du stehst also nicht alleine da.

gruss

[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