Hi Al,

>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.

statistics about the folders: I guess this keeps you from just scanning the top/currently expanded level, which is the windows (and appropriate) way of speeding up display. WHich statistics do you need ?

>The challenge: make the UI as responsive as possible.
as possible ? Even with a timer/semaphore based solution you can easily get "reactions" after 100ms. Enhancing the "scanning part" will get you more responsiveness.

>
>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.

Uuuumhhhh, I'ld be careful to spawn more than one separate process. There are quite a few scenarios where this will take longer than just spawning one process, although some situations could benefit. The deciding parameter here is probably not the CPU, but the physical disk / its channel. I'm quite sure scanning c,d,e on one physical disk concurrently will take longer than sequentially. Scanning 3 separate physical disks on an U160-SCSI strang should be faster concurrently, but is it worth to handle all these possible differences by program ?

>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:

Possible methods:
a)Spawn a process and use a table as a semaphore, check in calling program via timer. Easy and dependable if you follow multiuser practices (always try to lock), but not the "most responsive" due to timer latency.

b)Span a process and use DDE for intraprocess communication. Cons: DDE is legacy technology, sometimes a PITA and a bit more code to implement. Pro: DDE implements asynchrone processing AND defined vfp callback functions right out of the box. See your fpw(!) docs for that. Standardized "most responsive" but problematic/more work to shuffle information over into the TV.

c) create an actuiveX Exe, give it a reference of the properties to be filled, fill the TV datastructures directly from the other process. Data transfer very easy and done by the other process, but transferring data often across COM boundries takes time. Set a semaphore property and check this with a timer.

d)There are Callback's in the download section and there is one by Remus Rusanu: I haven't tried those yet...

I'ld get separate measurements for the times needed for each step and accordingly select one of the methods (GD&R).

HTH

thomas