Programm blockiert ganz Windows

[Gruber_Hans_12345]

Zitat:

Zitat von samso (Beitrag 1220310)

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:

Zitat von Jasocul (Beitrag 1220359)

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:

Zitat von Gruber_Hans_12345 (Beitrag 1220362)

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

[Gruber_Hans_12345]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220321)

Zitat:

Zitat von samso (Beitrag 1220310)

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

[Morphie]

Bist du sicher, dass du nirgends SetPriorityClass verwendest?
Durchsuche mal den gesamten Code danach... Unter umständen auch den Code deiner Fremdcontrols (falls du den Code hast)

[Gruber_Hans_12345]

Zitat:

Zitat von Morphie (Beitrag 1220377)

Bist du sicher, dass du nirgends SetPriorityClass verwendest?
Durchsuche mal den gesamten Code danach... Unter umständen auch den Code deiner Fremdcontrols (falls du den Code hast)

Nix gefunden aber auch ein SetPriorityClass dürfte doch nur dann den einen Prozessor beeinflussen oder?
Ich habe ja nur 25% CPU Last auf das gesammte System gesehen in dem Fall ..

[Captnemo]

Wenn ich deinen ersten Post lese, dann steht da:

Zitat:

(zb per IBX Daten abruft, oder einfach ne große schleife, wo was gemacht wird

was ist denn mit der großen Schleife? Hast du da mal mir Application.ProcessMessages experimentiert?
Manchmal ist es bei solchen Sachen auch ganz hilfreich, wenn man sich eine Logdatei mitschreibt und quasi jeden Schritt eine Zeitaufwendigen Funktion mit einem Zeitstempel mitloggt. So kann man dann explizit die verursachende Zeile finden.

Delphi-Quellcode:

procedure log(s: string);
var
  tc, tdiff: Cardinal;
  f: Textfile;
  logfile: string;
begin
  tc:=GetTickCount;
  tdiff:=tc-stc;  
  logfile:=extractfilepath(application.exefile)+'log.txt';
  Assingfile(f, logfile);
  if fileexists(logfile) then append(f) else rewrite(f);
  writeln(f, inttostr(tdiff)+' '+s);
  closefile(f);
  application.processmessages;
end;

Das hab ich mal so aus dem Kopf hier geschreiben. Also wenn Fehler drin sind, reißt mir nicht den Kopf ab.

in der unit noch die stc: Cardinal deklarieren.
Und am begin der fraglichen Funktion stc:=gettickcount;
und dann nach bedarf ein log('jetzt wir SQL.open ausgeführt'); setzen.

Hinterher kannst du in der Logdatei recht genau sehen, wo die Zeit verbraten wurde. Möglicherweise hilft das bei der Ergründung des Problems.

Wenn's sinnvoll ist, dann kann man auch noch andere Variablen mit übergeben und loggen, damit man ggf. auch auf unlogische Daten oder so prüfen kann.