The problem: scan a disk folder and its files (plus its subfolders and files), or one or more complete drives and gather statistics about the folders and files.

The challenge: make the UI as responsive as possible.

My current approach uses a Treeview control and populates it to simulate the Windows Explorer. At the moment it is slow to start because it scans all of drive C: by default which takes some time, then populates the Treeview with all those results, which also takes quite a bit of time. However, once that drive is scanned, examining any portion of it in detail is crisp and responsive.

Delayed instantiation (similar to only showing the first page of a multi-page pageframe at startup) is an obvious way to reduce start up time but further digging down into the treeview is sluggish as more folders and files are progressively scanned.

I'm wondering about spawning one or more separate processes (call them "disk" processes), each of which could scan a drive or folder tree, while the main program handles the UI. By having separate threads of execution, the slow but not CPU-intensive disk processing could run asynchronously from the CPU-intensive UI building (esp. the Treeview population), potentially yielding a faster start and crisper response. This approach would also allow speculative execution e.g. if a user is on a network and has network drives mapped, these could be scanned in the background while the user may be looking at statistics of local drive C:. If they then decide to look at a mapped drive in detail, bingo! the results are already there, no waiting.

The combination of a separate process plus intelligent use of speculative execution might also improve the responsiveness of delayed instantiation.

I'm not an expert on COM nor on callbacks (if that's what may be required here) and I'd welcome any advice on:

- Getting a separate "disk" process (COM or whatever) to asynchronously run a scan job defined by the UI process (i.e. the UI process continues to do other things)
- Getting the disk process to report back to the UI process when it has finished
- Getting the UI process to respond to the "I'm finished" message from the disk process
- Interrupting the disk process to stop it, or re-task it with a different drive/folder.

TIA.