TJvTimer

[Luckner]

Hallo,

ich habe eine DBGrid, das über ein Dataset mit einer Tabelle verbunden ist. Dann existiert ein TJvTimer. Das Interval ist eingestellt auf 30000.
Folgender Code:

Delphi-Quellcode:

procedure TFramePlannung.TimerPlanungTimer(Sender: TObject);
begin
  DatamodulePlannung.DataModule5.IBDataSetGridPlannung.Close;
  Datamodule5.IBDatabasePlannung.DatabaseName := dbpfad;
  DatamodulePlannung.DataModule5.IBDataSetGridPlannung.Open;
end;

Theoretisch müsste sich der Inhalt des DBGrids ändern (falls sich die Einträge in der Tabelle geändert haben) Es tut sich jedoch nichts. Der TJvTimer funktioniert jedoch, weil wenn ich nur;
DatamodulePlannung.DataModule5.IBDataSetGridPlannu ng.Close;
mache, dann bekommen ich eine leere Tabelle. Woran kann es liegen, dass die Daten nicht aktualisiert werden.
Danke, Luckner

[himitsu]

Das TJvTimer-Event wird standardmäßig in einem Thread ausgeführt.

Und dafür, dass du unsynchronisiert auf die VCL zugreifst, wirst du vollkommen zu Recht mit Fehlverhalten bestraft. :warn:



DataSet.DisableControls und EnableContols im Haupthtread
eventuell auch/alternativ die DataSource vom Grid abhängen

und dann kann man das DataSet gern in einem Thread aktualisieren



Alternativ im Thread ein neues DataSet holen
und das danach dann im Hauptthread schnell umhängen.

[Jim Carrey]

Zitat:

Das TJvTimer-Event wird standardmäßig in einem Thread ausgeführt.

Muss dafür Threaded nicht auf True stehen? Ich meine es steht standardmäßig auf False, oder?

[himitsu]

Hab den schon lange nicht mehr genutzt, aber schnell nochmal nachgeguckt und die Doku meint auch True.
http://wiki.delphi-jedi.org/wiki/JVC...Timer.Threaded

[Jim Carrey]

Aber wenn der auf True ist, läuft er doch im Hauptthread und synchronisiert alles.
So ist jedenfalls mein Kenntnisstand.

Ich würde aber eh auf den TTimer umstellen. TJvTimer bringt hier keinerlei Vorteil.

[himitsu]

Nee nee, wenn Threaded=True, dann läuft das Event in einem Thread.
Und wenn False, dann wird intern sowieso TTimer verwendet. :stupid:


Wenn die Anfrage "länger" dauert, dann wäre ein Thread schon OK, ABER die VCL darf von dem Thread garnichts mitbekommen
und natürlich auch die DB-Connection muß mit Threads klar kommen.

[Jim Carrey]

Zitat:

Wenn die Anfrage "länger" dauert, dann wäre ein Thread schon OK, ABER die VCL darf von dem Thread garnichts mitbekommen

Ich spreche in meinen Threads ständig die VLC an und hatte bisher noch nie Probleme.
Wie sonst soll man einen Fortschrittsbalken steuern?

[Luckner]

Habe jetzt einiges ausprobiert aber leider ohne Erfolg. Was mich wundert, dass wenn ich das Dataset.close setze, dann ist das Grid leer. Also reagiert die VCL auf den Timer. Ich muß mal schauen, ob das Grid (auch von Jedi) nicht irgendeinen Cache hat.

[Aviator]

Zitat:

Zitat von Jim Carrey (Beitrag 1349709)

Zitat:

Wenn die Anfrage "länger" dauert, dann wäre ein Thread schon OK, ABER die VCL darf von dem Thread garnichts mitbekommen

Ich spreche in meinen Threads ständig die VLC an und hatte bisher noch nie Probleme.
Wie sonst soll man einen Fortschrittsbalken steuern?

Du kannst schon mit deiner GUI aus einem Thread "sprechen". Aber du musst die Aufrufe vorher mit Synchronize() oder Queue() synchronisieren. Aus Threads würde ich aber immer ein Event feuern anstatt direkt darauf zuzugreifen. Das Event handled dann alles was es soll. Und ein Event muss dann auch mit Sychronize(OnFinish) aufgerufen werden.

[himitsu]

Die VCL ist per se nicht threadsave, daher darf man niemals unsynchronisert darauf zugreifen, da es immer zu Problemen kommen kann.

Einiges der VCL nutzt ausschließlich Messages (nur ein SendMessage in der Methode ... dann synchronisiert sich das "zufällig" von selber)

Zitat:

Zitat von Jim Carrey (Beitrag 1349709)

Wie sonst soll man einen Fortschrittsbalken steuern?

TThread.Synchronize, TThread.Queue, threadsichere Listen, Windows-Messages oder ähnliches.
Oder aucg Events im Thread setzen und in der VCL (z.B. Timer) reagiert jemand da drauf und liest das Ergebnis synchronisiert aus, wenn er Zeit hat.

SendMessage der besser PostMessage ... 'ne ProgressBar ist ja auch nur 'nen Windows-Control und da kennt die WinAPI eine pasende Message, um das zu steuern.