Custom Query (518 matches)

Presently, the only way to know when these commands are completed is by watching the hard drive light or waiting for the copied or moved file(s) to appear in the container. If it is one small file, one may not see the end result unless the container is refreshed.

Steven stated the following:

The are several issues. We need to decide where and how to do the notification and we need to define what progress means. We can probably do the notifications to one of the lower status windows. Defining what progress is is somewhat more difficult. We use DosCopy? internally, so a naive implementation would update the progress after each file copy completes. This is clearly not optimal when copying large files. A better solution would be to monitor progress in a thread that would monitor both the residual file count and the remaining space on the destination volume. These two combined could provide a reasonably accurate measure of progress. It's not sufficient to just monitor disk usage, since all sorts of things can happen to make this measure just plain wrong.

This all gets more interesting when we start a second copy while the first is still in progress. It's even more interesting if the copy is to a different volume. What is our definition of progress in this case?

This enhancement will rework GetPString to move the strings in fm3dll.str to fm3res.rc stringtables. The external interface to GetPString will remain unchanged. GetPString will handle caching strings in memory. It will also know how to build strings longer than the 256 character stringtable limit.

The purpose of this enhancement is to make NLS support easier to implement. It should also make string maintenance simpler overall.