Programm blockiert ganz Windows

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

[p80286]

Zitat von Gruber_Hans_12345:

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

Wenn das "open" lange braucht, dann hat der DB-Server gut zu tun. Da der aber auf einer ganz anderen Maschine sitzt sollte das ****egal sein.
Wenn Du dann die Daten abholst könnte es etwas Last geben.
Das beschriebene Verhalten finde ich sehr seltsam.

Gruß
K-H

[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

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