List files in directory

[Netwatcher]

Hello, I've been trying to get a list of files from given directory in C++ (with win32)
but i encountered some weird problems

//test snippet
#include <windows.h>
#include <stdio.h>
#include <iostream>

int main()
{

//find file data	
    WIN32_FIND_DATA findFileData;
 HANDLE hFind = FindFirstFile((LPCSTR)"C:\\Documents and                    
Settings\\Me\\Desktop\\Pictures", &findFileData);


//print it out
        std::cout <<"Files in dir:" <<std::endl;
	std::cout <<(char*)&findFileData.cFileName<<std::endl; //problem might be here
   

    char pause;
    std::cin>> pause;
    return 0;
}

my output is:

Files in dir
      Pictures

and I'm certain that it's a folder, not a file...

even when I do

 FindNextFile (hFind, &findFileData)

I'm still getting "Pictures"!
anything wrong with the code?
why am i not getting an actual file name?
wondering if it's my WCHAR to char* cast...(ugly isnt it?)


P.S.
is there a quick way to find the number of files in a directory?
(I am using VC++ 2008 with Windows XP Pro)

Thank you in advance,
Netwatcher.

[weaknessforcats]

I believe a folder is a type of file.

I assume you have read this: http://msdn.microsoft.com/en-us/libr...18(VS.85).aspx

[Netwatcher]

Yeepy...

So, i got that all good and figured out :p

//this goes to superduperwhat.cpp
#include <windows.h>
#include <stdio.h>
#include <iostream> 
char* locjpg = "C:\\Documents and Settings\\yair\\Desktop\\UNIMPICS\\*.jpg";
char* locbmp = "C:\\Documents and Settings\\yair\\Desktop\\UNIMPICS\\*.bmp"; 
char* arr[50];
char* nfilen;


int main()
{
	char desOfile[80]; //destination of file, load to a LPDIRECT3DTEXTURE9
    WIN32_FIND_DATA findFileData;
	HANDLE hFind = FindFirstFile((LPCSTR)locjpg, &findFileData);
	std::cout <<"Picture files in dir:" <<"\n"<<locjpg<<"\n"<<locbmp<<"\n\n"<<std::endl;
	std::cout <<findFileData.cFileName<<"\n"<<std::endl;
	nfilen = findFileData.cFileName;
	strcpy(desOfile,"C:\\Documents and Settings\\yair\\Desktop\\UNIMPICS\\");
	strcat(desOfile,nfilen);
	
	
//change to something to navigate between images, add bmp for search 
	for (unsigned f=0;f<20;f++) //change 
	{
		//tomalloc	
		FindNextFile(hFind,&findFileData);
		arr[f] = findFileData.cFileName;
		strcpy(desOfile,"C:\\Documents and Settings\\yair\\Desktop   \\UNIMPICS\\");
	    strcat(desOfile,nfilen);
		std::cout <<arr[f]<<std::endl;
		std::cout<<desOfile<<"\n\n"<<std::endl;
          /*arr[f]=desOfile;  for actual app IMPORTANT*/

		
	} 


	

	
	char pause;
    std::cin>> pause;
    return 0;
}

O.K. so everything is nice and happy until the for loop, how do i know how many files are in the directory so i can know how many times to loop? and maybe how many chars i need for "arr".


Was that a squirrl?
Netwatcher.

[weaknessforcats]

You stay in the loop until FindNextFile returns FALSE. The call GetLastError and look for ERROR_NO_MORE_F ILES.

If you counted the number of times FindNextFile returned TRUE, then you have the number of files.

Be sure to read the MSDN page for FindNextFile.

[Netwatcher]

Umm.... it just returns the last file it finds(the same file again and again) until i tell it to stop!

Edit: HAHA no need to actually check for the error but thx for pointing my attention at the fact that it returns something if it fails... forgot about that(yep, stupidity gets over me sometimes, well really often)

while(FindNextFile(hFind,&findFileData))
	{
		
		f++;
		arr[f] = findFileData.cFileName;
		strcpy(desOfile,"C:\\Documents and Settings\\yair\\Desktop\\UNIMPICS\\");
		strcat(desOfile,nfilen);
		std::cout <<arr[f]<<std::endl;
		std::cout<<desOfile<<"\n\n"<<std::endl;
				

	}

this looks much more neat then the last one and works well.

not paying attention to details gets me into panic

for the Left4Dead players:
"director_panic _forever 1;director_forc e_panic_event 1;z_spawn witch;z_spawn tank"
bind that with the quotes to any key and watch ur friends run away in fear...

[Banfa]

I don't know what you think this

    arr[f] = findFileData.cFileName;

does but probably not what you think. arr ends up as an array of pointers all pointing to the same buffer so all point to the same data, the last file you found.

[Netwatcher]

*headscratch...
so what do i need to do in order to save this the right way?
its not directed to the last file i found its directed to nothing, say i have exceeded the length of the streamsize when i try to print out arr[element]
Edit:
my right- to actually store the letters inside the (char*) in the spacific element of the array! (it is a char* array)
cant find a str method for this >,< or is there?

[Netwatcher]

so what do i need to do to findFileData?

[Netwatcher]

well think i made my work difficult cos arr is an array of pointers >,<
how else can i store whole strings in a non-pointer way?

[unauthorized]

vector<string>
This situation just calls for it.
If you use Unicode compiler settings replace string with wstring.

#include <vector>
#include <string>

using namespace std;


vector<string> vfList;
vfList.push_back("file1.txt");
vfList.push_back("file2.txt");
// keep pushing file names as long as you want

vector<string>::iterator itr;
for(itr = vfList.begin(); itr != vfList.end(); itr++)
{
	// Do actions with each file.
	// Use itr->c_str() to get the string buffer
	// or *itr to get the actual C++ string object.
}

Now, I'm not really sure why you use the raw Windows API, but I'd suggest scraping this whole thing and using Boost.Filesyste m instead.
The Win32 API was designed for C programmers some 15+ years ago. Even Microsoft doesn't want it anymore (see .NET).

[Netwatcher]

Thanks!
using multi-byte charset, :p this vector thing is new to me gonna read on that some
vector doesnt seem to have this method.
do i need to a include a .lib or do anything special before using vectors?

some time later in the day>>
Darnit! its a '::' method (I'm tired...) was just playing around and found it.





If the world is crashing down on you,
check for missing semicolons.
Netwatcher.

[Netwatcher]

Damn i didnt notice u using the namespace...
I was so frustrated why it won't work when i just do "vector<string> "...

or do i need to
the while loop goes through files in the directory
the "findFileData.c FileName" is a CHAR(WCHAR in unicode)
do i just use push back in the while loop?
does that create a new element or creates and stuffs a new element?

int main()
{
	
	char desOfile[80];
	std::vector<string> victor;
	std::vector<string>::iterator itr;

    WIN32_FIND_DATA findFileData;
	HANDLE hFind = FindFirstFile((LPCSTR)locjpg, &findFileData);
	std::cout <<"Picture files in dir:" <<"\n"<<locjpg<<"\n"<<locbmp<<"\n\n"<<std::endl;
	std::cout <<findFileData.cFileName<<"\n"<<std::endl;
	nfilen = findFileData.cFileName;
	strcpy(desOfile,"C:\\UNIMPICS\\");
	strcat(desOfile,nfilen);

	
	
	for(itr = victor.begin();itr!=victor.end();itr++)
	{
		victor.push_back(findFileData.cFileName);
		strcpy(desOfile,"C:\\UNIMPICS\\");
		strcat(desOfile,"\\");
		strcat(desOfile,nfilen);
		std::cout<<desOfile<<"\n\n"<<std::endl;
		
	

	}

say i have that, what does <string> should be?


"oh i forgot u used the std..."
Using STD in your source code just doesn't sound right anymore...
Netwatcher.

[Netwatcher]

Yeepy KEE.I.A

Damn me... forgot u used the namespace again... (string)
nyway...

after a nightmare of trial and error and reading MSDN...
i got it... i finally got it :D
got it all figured out and i probably should stop writing everything I'm panicing with... (see silly posts above)

Thank you so much.
I'm not gonna use arrays again!!! (wait what? just kidding)
the iterator doesnt appear to have any method called c_str though.

for the sake of knowledge, here is the complete, functional while loop

	while(FindNextFile(hFind,&findFileData))
	{
	    int temp;	
		victor.push_back(findFileData.cFileName);
		strcpy(desOfile,"C:\\UNIMPICS\\");
		strcat(desOfile,nfilen);
		cout<<desOfile<<"\n\n"<<endl;
		cout<<victor[f]<<endl;
		f++;
	}
}

Everybody's got a brain,
learn how to hack it, and the world is yours!
Netwatcher.

[george666]

Now, I'm not really sure why you use the raw Windows API, but I'd suggest scraping this whole thing and using Boost.Filesyste m instead.
The Win32 API was designed for C programmers some 15+ years ago. Even Microsoft doesn't want it anymore (see .NET).

What is this **** ?!!!!
Under Windows, you must use Win32 api. Period.
All OS from Win 95 to Windows 7 are written in C, C++, ASM Win32, with the Win32 api
All Windows softwares are written with Win32 api (MFC is a wrapper)
All Windows games are written with Win32 api (DirectX and OpenGL)
Incredible to read such things...

[Banfa]

Under Windows, you must use Win32 api. Period.
All OS from Win 95 to Windows 7 are written in C, C++, ASM Win32, with the Win32 api
All Windows softwares are written with Win32 api (MFC is a wrapper)
All Windows games are written with Win32 api (DirectX and OpenGL)

This is partly a matter of semantics, if a wrapper you use then uses the WIN32 API you are still not using it and do (should) not really need to know anything about it only about the interface the wrapper you are using defines.

Using WIN32 directly is definitely not what Microsoft want you to do nor for that matter do they want you using MFC. Both of these are out-dated forums of writing programs for Windows, although I imagine they are both still used.

The prefered method for creating Windows application is now .NET. It would not be unreasonable to assume that the Windows implementation of the .NET Framework makes some use of the WIN32 interface when implemented on the Windows platform, however Windows is not the only platform that the .NET framework has been implemented on so using .NET is not implicitly using WIN32.

In a complex system like Windows you use the interface of your choice and you do not worry too much about what interfaces that interface uses.

So you blanket statement that all Windows development uses the WIN32 API make be technically correct if you delve down through the layers of code deeply enough but it is not the environment that most Windows application programmers use and for straight programming it is certainly not in very common usage any more.

Your view is out-dated and presented in a belligerent manner and not that useful.