Neues Fenster als neuer Prozess

[TomyN]

Hallo,

Ich stehe gerade vor folgendem Problem:

Ich habe eine Anwendung, die ein Setup-Fenster öffnet.
In dem Setup-Fenster befindet sich ein TShellTreeView.
Das 'Befüllen' dieser TShellTreeView dauert, gerade wenn Netzwerkgeräte vorhanden sind, sehr lange.
Während dieser Zeit friert auch das Hauptprogramm ein.
Wenn ich die Box selber füllen würde, dann würde ich das einfach in eine Thread packen und gut. Aber mit einer visuellen Komponente kann ich das ja nicht so einfach.

Jetzt überlege ich, ob ich das Setup-Fenster sinnvoll in einem eigenen Thread (oder gar als eigner Prozess) laufen lassen kann, oder ob es eine Möglichkeit gibt, das Füllen der TShellTreeView in einen Thread auszulagern (oder es eine andere Komponente gibt, die diese Problematik nicht hat).

[himitsu]

Eigener Thread mit "eigener" VCL geht nicht, also bleibt nur der eigene Prozeess.
Eine DLL (ohne LaufzeitPackages) mit eigener VCL, da könnte man deren VCL auch in einem anderen Thread laufen lassen.

Tja, oder eben doch selber im Thread die Daten holen und dann schnell in die ListView einfügen.


Den WindowsFileCache auszunutzen ist auch nicht gaaanz sicher.
Also im Thread die Verzeichnisse einlesen ansehen (in den SystemCache vorladen) und dann sich "schnell" den ListView aktualisieren lassen.

[dummzeuch]

Was dauert denn so lange? Zusammenstellen der Daten oder das Füllen der Daten in das UI? Ich würde auf ersteres tippen und versuchen, das in einen Thread auszulagern. Der greift dann nicht auf die VCL zu und alles ist gut. Erst wenn er durch ist, werden dann die Daten im Hauptthread in das UI übertragen.

[TomyN]

Die TShellTreeView füllt sich selber mit der aktuellen Dateistruktur. Das dauert teilweise eine halbe Minuten.
Dafür hat man dann die entsprechenden Symbole, die virtuellen Ordner ('Downloads') etc, halt das Bild,
das der User von einer Windows Dateiauswahl gewohnt ist.