[bezumes]

Все-равно, даже когда я поставил *.* чтобы все посчитать, он мне как-то неправильно считает. Например в корне диска d у меня на два
меньше чем он считает, а на с всего шесть, а он считает 18.

Код:

char temp[100];
	for(int i=0;i<26;i++)
	{		
		hFirstFile=0;
		WIN32_FIND_DATA FindFileData;
		HANDLE hf;		
		if(i==2)
		{
		m_info += " В корне диска C ";
		hf=FindFirstFile("c:\\*.*", &FindFileData);
		//hFirstFile++;
		}
		else
		if(i==3)
		{
			m_info += " В корне диска D ";
			hf=FindFirstFile("d:\\*.*", &FindFileData);
			//hFirstFile++;
		}
		else
		{
			hf=FindFirstFile("e:\\*", &FindFileData);
		}
			if (hf!=INVALID_HANDLE_VALUE)
			{
				do
				{					
					hFirstFile++;
				}
				while (FindNextFile(hf,&FindFileData)!=0);

				itoa( (int)hFirstFile, temp, 10 );
				m_info += (CString)&temp[0]; m_info += " Файлов и папок";m_info += "\r\n";
				FindClose(hf);
			}
	}
	UpdateData(false);

aESThete, в коммандной строке Win XP (да и в DOS'е), получаем: dir *,*, dir *,?* и dir *,??* - выводятся все файлы и папки (с расширением и без). dir *.? - выводятся файлы и папки, с расширением в один символ и без расширения (не более одного символа). Из книжки В. Э. Фигурнов "IBM PC для пользователя": Символ ? обозначает один произвольный символ или отсутствие символа в имени файла или в расширении имени файла. Так что ты не прав. К сожалению - НЕ МЕНЕЕ нельзя зделать.

А почему тогда, например в стандартном xp поиске *.* это все файлы *.?* файлы с расширением более 1 символа

[Diseased Head]

bezumes

А почему тогда, например в стандартном xp поиске *.* это все файлы *.?* файлы с расширением более 1 символа

Проверил - действительно не более одного символа (я поиском редко пользуюсь). А почему это? Да потому что: программеры в Microsoft напортачили с этим поиском (так как DOS раньше был, и коммандная строка, почему-то, иначе работает). Это, думаю, одна из причин глюков... Или это издёвка над пользователями - что-б жизнь малиной не казалась.

[Vovchick1]

Все-равно, даже когда я поставил *.* чтобы все посчитать, он мне как-то неправильно считает. Например в корне диска d у меня на два меньше чем он считает, а на с всего шесть, а он считает 18.

1. Может скрытые или системные не отображаются.
2. Может переменную "счётчика" не обнулил до начала циклов, и вней присутствуют левые данные.

Например в корне диска d у меня на два меньше чем он считает

3. Не вкурсе насчёт этих функций, но когда ищеш файлы по маске (стандартными средствами Pascal или VB) обычно первые два "файла": ".."
И "..." (Или что-то в этом роде, уже непомню).

[aESThete]

Vovchick1
см. мой исходник: (hFirstFile.name != "." && hFirstFile.name != "..")
это ссылки на себя и на предка (но откуда они в корне?!)
прекрасно видно, если смотреть каталог DiskEdit'ом

Diseased Head

программеры в Microsoft напортачили с этим поиском

это точно, с отдельно стоящим(и) "?" глючок-с
для пробы создал
readme.
readme.t
readme.tx
readme.txt
под XP dir *.*, *.?* и т.д. дают одинаковы е результаты
но read?me (файлов не найдено) и read*me (файлы найдены) отрабатывает чётко

[Vovchick1]

aESThete

см. мой исходник: (hFirstFile.name != "." && hFirstFile.name != "..")

Пардон виноват незаметил!!!

это ссылки на себя и на предка (но откуда они в корне?!)

Насчёт ".." вкурсе, а что за "." незнал, будем знать!!!

прекрасно видно, если смотреть каталог DiskEdit'ом

Это ты про:

Может скрытые или системные не отображаются.

А насчёт:

Может переменную "счётчика" не обнулил до начала циклов, и вней присутствуют левые данные.

[bezumes]

Может переменную "счётчика" не обнулил до начала циклов, и вней присутствуют левые данные.

Сам счетчик в начале цикла for обнуляется. возможно надо HANDLE hf обнулить. Я попробЫвал написать hf=INVALID_HANDLE_VALUE; и у меня вообще отрицательные значения получились. хотя если в конце стоит FindClose(hf); то этого не надо делать

Код:

         CString bukva[26]={'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z'};
	char temp[100];	
	for(int i=0;i<26;i++)
	{		
		hFirstFile=0;//обнуляем 
		hFirstFile=0;	// и здесь обнуляем
		WIN32_FIND_DATA lpFindFileData ;
		WIN32_FIND_DATA FindFileData;
		HANDLE hf;	
		hf=INVALID_HANDLE_VALUE;
		hf=FindFirstFile(_T(bukva[i]+":\\*.*"), &FindFileData);
		if (hf!=INVALID_HANDLE_VALUE)
			{
				do
				{hFirstFile=0;hFirstFile=0;
					
					
					if ((FindFileData.dwFileAttributes&&FILE_ATTRIBUTE_DIRECTORY) == FILE_ATTRIBUTE_DIRECTORY)
					{
						hFirstFile++;
					}
					else
					{
						hFirstFile1++;
					}					
				}
				while (FindNextFile(hf,&FindFileData)!=0);
				m_info += " В корне диска "+_T(bukva[i]+" ");
				itoa( (int)hFirstFile, temp, 10 );
				m_info += (CString)&temp[0]; m_info += "папок";m_info += "\r\n";
				m_info += " В корне диска "+_T(bukva[i]+" ");
				itoa( (int)hFirstFile1, temp, 10 );
				m_info += (CString)&temp[0]; m_info += " файлов";m_info += "\r\n";
				FindClose(hf);
			}
	}
	UpdateData(false);

[bezumes]

В итоге получилось вот так:только долговато ищет(у меня 14.19 сек, а что будет на более слабых компах ), ну и результаты от стандартного поиска отличаются(но немного)

Код:

Find(CString(bukva[i])+CString(":"));

Код:

void CSysInfoDlg::Find(CString szPath)
{
CFileFind F;
CString S=szPath+"\\*.*";
BOOL bFlag=F.FindFile(S);
while(bFlag)
{
bFlag=F.FindNextFile();
if(F.IsDirectory()==TRUE && F.IsDots()==FALSE)
{
	p++;	
Find(F.GetFilePath());
}
else
{
	f++;
}
}
F.Close();
}