OnTimer wird nicht ausgelöst

[Valle]

Zitat:

Zitat von bigben37

delay ist dein Freund. Damit werden andere Prozesse weiterhin verarbeitet.

Das Sleep in meiner Anwendung war ja nur ein Beispiel. *g* Chemiker macht in dieser Zeit ja eine Datenbank-Abfrage, welche die entsprechende Zeit die mein sleep() verschlafen hat, mit suchen in der Datenbank verbringt. (Oder mit warten auf eine Antwort des Datenbank-Servers, das hängt eben von der DB ab)

Mit freundlichen Grüßen,

Valle

[bigben37]

Mist :oops:

Aber eigentlich kann das verzögern ja nur von dieser Zeile kommen FAbfrageClass.MSErmitteln;, da die drei anderen Zeilen nur zum einfachen zeichnen oder eine Zuweisung sind. Also müssten wir diese Prozeure mal zu Gesicht bekommen. (Ich hoff, meine Argumetation ist wenigstens halbwegs richtig :mrgreen: )

[Chemiker]

Hallo,

Delphi-Quellcode:

procedure TAbtfrageClass.MSErmitteln;
var
  I: integer;
begin
  with FpFIBDataSetAbfrage do
  begin
    Close;
    SelectSQL.Text:= 'SELECT DISTINCT mw_msid FROM mw_tabelle';
    GenerateSQLs;
    Open;    
    while not EOF do
    begin
        // Die MSId-Bezeichnung aus der Datenbank wird in einer StringList
        // gespeichert. Diese Bezeichung ist auch gleichzeitig die Spalten-
        // bezeichnung für die PIVOT-Tabelle.
      FMSListe.add(FieldByName('mw_msid').AsString); 
      next;       
    end; 
  end;
end;

das ist die Procedure. Damit werden alle Datensätze durchlaufen und das kostet Zeit. Das ist der Grund warum ein Fenster mit einer Gauge angezeigt werden soll.

Bis bald Chemiker

[Satty67]

Nach "next" ein Application.ProcessMessages. Wobei das nicht bei jedem Schleifendurchlauf aufgerufen werden sollte, sondern nur alle x Durchläufe.

Falls die Variable i in der Schleife hochgezählt wird:

Delphi-Quellcode:

if (i mod 100) = 0 then Application.ProcessMessages

Statt einem Timer wäre es in meinen Augen auch elegant, MSErmitteln eine Procedure zu übergeben, die die ProgressBar oder Gauge aktualisiert. Die Procedure statt Application.ProcessMessages aufrufen, was innerhalb der Procedure erledigt würde.

[Chemiker]

Hallo Satty67,

die Schleife wird nur 25 durchlaufen. Das Problem ist der SQL-Aufruf, weil er alle Datensätze durchläuft.

Bis bald Chemiker

[nahpets]

Hallo,

Delphi-Quellcode:

procedure TAbtfrageClass.MSErmitteln; 
var 
  I: integer; 
begin 
  i := 0;
  with FpFIBDataSetAbfrage do 
  begin 
    Close; 
    SelectSQL.Text:= 'SELECT DISTINCT mw_msid FROM mw_tabelle'; 
Application.ProcessMessages;
    GenerateSQLs; // Wie lange braucht der? Wenn lange, dann dahinter ein
Application.ProcessMessages;
    Open; // Solange der ackert, wird's vermutlich nichts mit dem Aktuallisieren der Gauge.   
Application.ProcessMessages;
    while not EOF do 
    begin 
        // Die MSId-Bezeichnung aus der Datenbank wird in einer StringList 
        // gespeichert. Diese Bezeichung ist auch gleichzeitig die Spalten- 
        // bezeichnung für die PIVOT-Tabelle. 
      FMSListe.add(FieldByName('mw_msid').AsString); 
      next;        
      Inc(i);
      // Zeit- und datenmengenabhängig größeren oder kleineren Wert nehmen.
      If i Mod 100 = 0 then begin
        Application.ProcessMessages;
      end;  
    end; 
  end; 
end;

Wie stehen die Start- und Endewerte für frmWarnhinweis.frmWarnung.Gauge1?
Woher weiß die Routine, wann sie den Endewert erreicht hat um ggfls. wieder von vorne anzufangen. Sind Start- und Endewert eventuell so gewählt, dass ein Progress + 10 eine so kleine Veränderung der Gauge liefert, dass der Fortschritt nur einfach nicht zu sehen ist?

Alternative: Lass den Timer weg und rufe die Methode

Delphi-Quellcode:

Timer1Timer(Sender: TObject);

in MSErmitteln auf:

Delphi-Quellcode:

procedure TAbtfrageClass.MSErmitteln; 
var 
  I: integer; 
begin 
  i := 0; 
  with FpFIBDataSetAbfrage do 
  begin 
    Close; 
    SelectSQL.Text:= 'SELECT DISTINCT mw_msid FROM mw_tabelle'; 
Application.ProcessMessages;
    GenerateSQLs; // Wie lange braucht der? Wenn lange, dann dahinter ein
Application.ProcessMessages;
    Open;    
Application.ProcessMessages;
    while not EOF do 
    begin 
        // Die MSId-Bezeichnung aus der Datenbank wird in einer StringList 
        // gespeichert. Diese Bezeichung ist auch gleichzeitig die Spalten- 
        // bezeichnung für die PIVOT-Tabelle. 
      FMSListe.add(FieldByName('mw_msid').AsString); 
      next;        
      Inc(i);
      // Zeit- und datenmengenabhängig größeren oder kleineren Wert nehmen.
      If i Mod 100 = 0 then begin
        Timer1Timer(Nil); // Gaugeposition verändern.
        Application.ProcessMessages;
      end;  
    end; 
  end; 
end;

[sirius]

Lasst doch bitte einmal dieses ständige Application.ProcessMessages! Dafür ist es überhaupt nicht da. Wie weiter oben bereits erwähnt wurde, muss die gesamte Datenbankgeschichte in einen eigenen Thread. Ja, das ist ein wenig aufwendig aber der Anwender deines Programms wird es dir danken.

[Hobby-Programmierer]

... vielleicht so?

Delphi-Quellcode:

procedure TAbtfrageClass.MSErmitteln;

  procedure Gauge_refresh(Value: Integer);
  begin
    frmWarnhinweis.frmWarnung.Gauge1.Progress:= frmWarnhinweis.frmWarnung.Gauge1.Progress+ Value;
    frmWarnhinweis.frmWarnung.Refresh;
    Application.ProcessMessages;
  end;
 
begin 
  with FpFIBDataSetAbfrage do 
  begin 
    Close; 
    SelectSQL.Text:= 'SELECT DISTINCT mw_msid FROM mw_tabelle';
    Gauge_refresh(10); 
    GenerateSQLs; // Wie lange braucht der? Wenn lange, dann dahinter ein
    Gauge_refresh(10);
    Open; // Solange der ackert, wird's vermutlich nichts mit dem Aktuallisieren der Gauge.   
    Gauge_refresh(10);
    while not EOF do 
    begin 
        // Die MSId-Bezeichnung aus der Datenbank wird in einer StringList 
        // gespeichert. Diese Bezeichung ist auch gleichzeitig die Spalten- 
        // bezeichnung für die PIVOT-Tabelle. 
      FMSListe.add(FieldByName('mw_msid').AsString); 
      next;        
      Gauge_refresh(5); // anpassen je nach Anzahl der Bezeichnungen
      end;  
    end; 
  end; 
end;

[edit] und natürlich muss der Timer weg

[blauweiss]

Zitat:

Zitat von sirius

Lasst doch bitte einmal dieses ständige Application.ProcessMessages! Dafür ist es überhaupt nicht da. Wie weiter oben bereits erwähnt wurde, muss die gesamte Datenbankgeschichte in einen eigenen Thread. Ja, das ist ein wenig aufwendig aber der Anwender deines Programms wird es dir danken.

Kann da nur zustimmen ! Application.ProcessMessages wird ja gerne als Allheilmittel empfohlen. Was fatal ist, wenn man nicht bedenkt, daß die GUI quasi parallel weiterarbeitet, inklusive FormClose, nochmaliger Aufruf einer Funktion über ButtonClicks etc.
Die nächste Frage ist schon vorprogrammiert -> "ich will mein Programm schliessen aber es tut sich nichts"....

Der saubere Weg ist ein Thread, der kontrolliert gestartet und beendet wird.

blauweiss

[NormanNG]

Hi,

mal ein anderer Ansatz:

SQL-Code:

SelectSQL.Text:= 'SELECT mw_msid FROM mw_tabelle group by mw_msid';

Evtl. dann ein "Ich mach was"-Hinweis nicht mehr nötig?