C / C++ / MFC

Re: CListCtrl Please Help !

21-Nov-06 1:59

As a simple trick you can assign size 0 to the intended columns,
using SetColumnWidth( nCol, 0 )
It works, but the user can enlarge the columns if he wants...
Smile | :)

toxcct21-Nov-06 3:02

toxcct

21-Nov-06 3:02

Bravoone_2006 wrote:
I have 7 columns ,(0,1,2,3,4,5,6,7)

excuse me, but from 0 to 7, it gives you 8 ones !!!

You don't know where to start ? ask a good friend

[VisualCalc 3.0][Flags Beginner's Guide]

Finding files older than a week

m.dietz20-Nov-06 23:39

20-Nov-06 23:39

Hi,

In a current tool, that copies Sources from a server, zips them and sends the zip-File to another server, I have to delete the intermediate zip-Files stored locally about after a week (so that they still are available if the recipient claims a transfer failure).

I can't use CTime procedures for determining that week as the tool itself was created as Win32 console application without MFC support, so I tried to get the Local Time with GetLocalTime(&now), convert this to a FILETIME and compare it with the FILETIME got from the creation date of the file to decide wether this file is to be kept or deleted. According to the help pages FILETIME holds intervals of 100 nanosecond, so a week would calculate to 7(days)*24(hours)*60(minutes)*60(seconds)*1000(milliseconds)*1000(microseconds)*10(intervals of 100 nanoseconds) = 6048000000000 intervals.

The help pages tell me that I have to copy the FILETIME to a LARGE_INTEGER before I can compare the dates so I tried the following code:

LARGE_INTEGER liNow,liFile;
liNow.LowPart = ftNow.dwLowDateTime;
liNow.HighPart = ftNow.dwHighDateTime;

liFile.LowPart = localDateCreated.dwLowDateTime;
liFile.HighPart = localDateCreated.dwHighDateTime;

if(liNow.QuadPart - liFile.QuadPart > 6048000000000)
{ ... }

Now I have the problem that none of my files reach the deletion part of the code, even files two weeks old only have a difference of 1604372500. Is something wrong with my calculation, my conversion to LARGE_INTEGER or is the whole approach faulty?

Hope anyone can help me
Martin Dietz

Viorel.21-Nov-06 1:37

Viorel.

21-Nov-06 1:37

How do you obtain the creation time of the file?

m.dietz21-Nov-06 3:57

21-Nov-06 3:57

When I use FindFirstFile, and FindNextFile in the loop afterwards, I get a lot of data stored in a WIN32_FIND_DATA structure, among others creationtime, lastAccessTime and LastWriteTime.
Hmm... Maybe I used the wrong member and should try ftLastWriteTime, as this doesn't change when copying. I'll try that approach and call back later (or tomorrow)

David Crow21-Nov-06 5:10

David Crow

21-Nov-06 5:10

m.dietz wrote:
When I use FindFirstFile, and FindNextFile in the loop afterwards...

Are you then calling FileTimeToLocalFileTime()?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

m.dietz21-Nov-06 20:23

21-Nov-06 20:23

Yes, as I'm calling GetLocalTime the File time has to be converted to Local Time too. It seems I just looked at the wrong filetime member of WIN32_FIND_DATA struct; after looking at ftLastWriteTime instead of ftCreationTime the files older than a week were correctly identified.

CPallini21-Nov-06 2:32

21-Nov-06 2:32

Take a look to:
FileTimeToSystemTime and related API's. Maybe are helpful.

David Crow21-Nov-06 3:33

David Crow

21-Nov-06 3:33

It is not recommended that you add and subtract values from the SYSTEMTIME structure to obtain relative times.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

m.dietz21-Nov-06 4:04

21-Nov-06 4:04

SYSTEMTIME structure is far less useful for calculating timespans than FILETIME. At SYSTEMTIME, the help pages even recommend converting it to FILETIME and then to LARGE_INTEGER structures before comparing (exactly what I was trying to do), but as I wrote above, I'll try to use a different timestamp item on the file to see if that corresponds with the real file date. Maybe simply the files were not recognized as one week old because they were moved in between...

CPallini21-Nov-06 5:14

21-Nov-06 5:14

Both of you have reason.

That stated, the following code works pretty well:

#include "stdafx.h"
#include <windows.h>
int main(int argc, char* argv[])
{
	OFSTRUCT ofs;
	if (argc <2) return -1;

	HFILE hFile;

	hFile = OpenFile(argv[1], &ofs, OF_READ);
	
	FILETIME ct, lat, lwt[2];


	SYSTEMTIME locTime;
	GetLocalTime(& locTime);

	BOOL  bSuccess= SystemTimeToFileTime( &locTime, &lwt[0]);

	bSuccess= GetFileTime( (HANDLE)hFile, &ct, &lat, &lwt[1]);
	
	LARGE_INTEGER li[2], liresult;

	li[0].LowPart = lwt[0].dwLowDateTime;
	li[0].HighPart = lwt[0].dwHighDateTime;


	li[1].LowPart = lwt[1].dwLowDateTime;
	li[1].HighPart = lwt[1].dwHighDateTime;

	liresult.QuadPart=li[0].QuadPart-li[1].QuadPart;

  if (liresult.QuadPart> 6048000000000L)
	{
		printf("more than a week\n");
	}


	
	CloseHandle((HANDLE)hFile);
	getchar();
	return 0;

}

The program compare the file given as its argument with the current system
time. I tested it.

What about your code? Maybe you're considering the wrong attribute (I don't believe you're modifying the files...)

Smile | :)

m.dietz21-Nov-06 20:31

21-Nov-06 20:31

It's exactly that: The files were copied to their location shortly before I took that debug attempt and so the "creation" time was just a few hours ago and I had too look for the "modification" time. After I changed the code to ftLastWriteTime (from the WIN32_FIND_DATA structure) I could identify the files older than a week without problems.

Thanks for your help
Martin Dietz

CPallini21-Nov-06 21:51