🚀 go-pugleaf

Tommy wrote:

>i did some tests, but i wont work. before the copy process starts i call

How does it "won't work"?
Does it compile?
Does it run?
Does it give larger values than you expect?
Smaller?
Sorry, but my mind reading machine is broken.


>
>This wont work because i cant subtract 2 FILETIME.

Yeah, I mentioned that you needed to mess with getting a FT into a
int64.  I'm not too proud of the way I did it, but..
typedef union uFT264{
	FILETIME	ft;
	DWORDLONG	i64;
}FT264;
	static	FT264		StartTime;
void updatetime()
{	FT264	now;
	FT264	remaining;
	FT264	elapsed;
	SYSTEMTIME	SystemTime;
	GetLocalTime( &SystemTime );
	SystemTimeToFileTime( &SystemTime, &now.ft );
	elapsed.i64 = now.i64 - StartTime.i64;
	FileTimeToSystemTime( &elapsed.ft, &SystemTime );
	FormatTime( &SystemTime, szCM_U_TIMECOPIED );

	remaining.i64 = ((BytesRemaining * (elapsed.i64/10000U)) /
(BytesSoFar+1))*10000U;
	FileTimeToSystemTime( &remaining.ft, &SystemTime );
	FormatTime( &SystemTime, szCM_U_TIMEREMAINING );


> Another problem ist that
>i cannot follow your idea how to solve. i understand that it is not good to
>divide so often a value by 10million.

What I really think isn't so good, is converting to floating point
when there's no need.

If you keep everything in FILETIME accuracy, then you don't need to
divide my 10 million. Just use FileTimeToSystemTime to convert to
hours:minutes:seconds.  But, if you keep everything at FILETIME
accuracy, there's a decent chance the multiply will overflow.
So, dividing the elapsed time by 10,000 reduces the chance of overflow
while still keeping a time accuracy of 1/1000th second. After the
calculation, you need to re-multiply by the same 10,000 to return the
FILETIME to it's original "accuracy" so that FileTimeToSystemTime can
decode it properly.