Jupp, es gibt nur
zwei drei Wege, um sowas zu lösen:
* Die Arbeit im Hauptthread, dann kann die
VCL dort halt so lange nichts machen.
(nur Grafik/Wartemauszeiger zu Beginn, währenddessen halt unbewegt und zum Schluß wieder weg ... in der Hoffnung Windows reagiert nach standardmäßig 3 Sekunden nicht mit "Fenster reagiert nicht mehr")
* Die Arbeit in einem Thread, dann kann der Hauptthread in Ruhe die Wartegrafik aktualisieren
* Arbeit im Hauptthread, aber dort wird z.B. über einen Callback oder regelmäßig ProcessMessages der Wartegrafik Zeit gegeben.
* Oder Arbeit im Hauptthread und die Wartegrafik im Thread.
Wir blenden z.B. bei längeren Aktionen, bzw. nach kurzem Warten, ein Fenster (nicht
VCL) ein, in einem anderen Thread erstellt und behandelt, wo per Button oder per Strg+ESC (GetAsyncKeyState) abgebrochen werden kann.
Unsere
DB-Komponenten haben eine Methode, womit man sie aus einem anderen Thread heraus abbrechen kann (also wo versucht wird dem
DB-Server ein Abbruchsignal zu senden, bzw. die Connection getrennt wird, wodurch die wartende Aktion im Hauptthread abbricht)
Ursprünglich auch versucht die
DB-Aktion in den Thread zu verschieben und das WarteZeugs im Hauptthread, aber trotz viel Arbeit mit Blocking, ConnectionPooling uvm. hatte es immer wieder mal geknallt, da ja öfters
VCL-Komponenten und Events ungeschützt an den Queries hingen.