Two questions.. yup, I know, I''ve been asking a lot of questions lately. 1) Is there any function that I can call to return an array of strings or character pointers or ANYTHING of that sort of what files/type of files are in a directory.. I want the ability to load a file into the game I am making, and originally I figured I could either have the person type in the name of the file they wanted, or every time they created a file it would save it''s name onto a text file... but both of those ways are a) cheesy, and b) annoying. So, I''m wondering if there is any way I could search a directory for files, or something similar..? 2) The LoadBitmap() function has me very confused. In both Windows Game Programming for Dummies and Tricks of the Windows Game Programming Gurus, that functions is mentioned, but never explained (though in the gurus book, he refers you to a different chapter where it is never mentioned)... there is no example of it in any help files I''ve found, but I did find: BOOL LoadBitmap( LPCTSTR lpszResourceName ); Return Value: Nonzero if successful; otherwise 0. Parameters: lpszResourceName Points to a null-terminated string that contains the name of the bitmap resource. Remarks Loads the bitmap resource named by lpszResourceName or identified by the ID number in nIDResource from the application’s executable file. The loaded bitmap is attached to the CBitmap object. Now... curious.. this seems simple enough.. I would add "bob.bmp" to the project, and then say "LoadBitmap("bob.bmp") or something similar, but how would I interact with it if it''s attatched to the CBitmap object? How would I attach a bitmap to a different object... how would I load multiple bitmaps? Thanks.. :] - Goblin "A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

OK here goes :

1. If you working under windows and are not afraid to use the Common Dialog of windows (you know the file open dialog of VC++ or WOrd, or any Windows 9X prog) then have a look at these as it will do exactly what you want, with a lot less fuss.

If you do not want to use the Common Dialog's, then look into FindFirst, FindNext API calls. Then loop though the files, and build up your own interface to display and allow the user to select the file they wish to use.

2. Loadbitmap loads bitmaps from the executable file itsself, so if you change your graphics you will have to provide a new executable for end uses, also the file sizes grow, and in some cases they grow exponentionaly (sp?).

Using LoadBitmap is easy, but only if you are going to be using MFC.

The following code will load a bitmap from a resource file, and set hbitTemp to the GDI handle for the bitmap.

        CBitmap bmpTemp;HBITMAP hbitTemp;bmtTemp.LoadBitmap("MYBITMAP.BMP");hbitTemp = (HBITMAP)bmpTemp;        

When you add the bitmap to the resource file, do not forget to remove the resource id from it otherwise the above code will not work, it will work if you subsitue "MYBITMAP.BMP" with the resource id IDB_MYBITMAPRES.

If you are loading bitmaps into something other than MFC (i.e. for DX's use) then I suggest that you use LoadImage() instead, as this will give you more control over the loading process, does not need MFC and returns an HBITMAP GDI Handle straight away.


Edited by - Steven on August 4, 2000 8:03:10 PM

I bow before you, Steven, you are infinitely usefull!

Although, now I have one problem...

I have both Borland 4.5 and Microsoft Visual C++ 4.0 on my computer. DirectX doesn''t work, really, at all with Borland, so I am forced to use Visual C++ for the game.

The MFC stuff for Common Dialouge scares me... I''m not near ready enough to delve into that, yet. I found the findfirst and findnext stuff in the compiler help on Borland, and tried it (in Borland)... it works, in Borland.

I tried compiling it in Microsoft Visual C++, and it doesn''t. It complained about missing _defs.h and dir.h... upon putting these in the include directory, it just got more pissed at me and threw out "unresolved extern _findfast" and "unresolved extern _findnext" at me.. (link errors, not compiler errors, strangely enough).

Any ideas? Any help?

Thanks! :]

- Goblin
"A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

OK, that's it I quit. I'm stopping work on all projects....

OK just kidding but really I know nothing about programming, and yet I help people with stuff I know nothing about....

right that's my rant over now down to the serious FindFirstFile / FindNextFile

WARNING - UNTESTED SOURCE CODE FOLLOWS. USE AT YOUR OWN RISK.

WIN32_FIND_DATA FindFileInfo;HANDLE hanFile;BOOL FbFound = TRUE;hanFile = FindFirstFile( "*.BMP", &FindFileInfo );if( hanFile == INVALID_HANDLE_VALUE ){   // Error, no files found. put in a call to GetLastError() to find out the exact reason for the error.}else{   // OK we have a file...   while( bFound )   {      // get the last file name here      bFound = FindNextFile( hanFile, &FindFileInfo );   }   FindClose( hanFile );}

the format of the WIN32_FIND_DATA struct is:

typedef struct _WIN32_FIND_DATA { // wfd     DWORD dwFileAttributes;     FILETIME ftCreationTime;     FILETIME ftLastAccessTime;     FILETIME ftLastWriteTime;     DWORD    nFileSizeHigh;     DWORD    nFileSizeLow;     DWORD    dwReserved0;     DWORD    dwReserved1;     TCHAR    cFileName[ MAX_PATH ];     TCHAR    cAlternateFileName[ 14 ]; } WIN32_FIND_DATA; 

where cFileName is the NULL terminated filename.

Anything else that needs to be said about this... nope i can not see anything else.

OK and here is the C way to do custom dialog boxes:

OPENFILENAME fname;static char fn[256]; // full pathchar filename[64]; // Filenamefname.lStructSize = sizeof(OPENFILENAME);fname.hwndOwner = hwnd; // insert your main windows hwnd herefname.lpstrFilter = "Text\0*.TXT\0C\0*.C\0\0\0"; //insert your own file types here.        // Do not forget to put \0\0 at the end of the filter linefname.lpstrFile = fn;fname.nMaxFile = sizeof(fn);fname.lpstrFileTitle = filename;fname.nMaxFileTitle = sizeof(filename)-1;fname.Flags = OFN_FILEMUSTEXIST;fname.lpstrCustomFilter = NULL;fname.lpstrInitialDir = NULL; // change this if you wantfname.lpstrTitle = NULL;fname.lpstrDefExt = NULL;fname.lCustData = 0;if(!GetOpenFileName( & fname ) ){   // no file was selected.}else{   // fn contains the file that was selected.}

oh and you will have to include COMMDLG.H as well to use the common dialog functions.

Phew, a lot odf typing there.

The book I got the info regarding the common dialog stuff is Windows 98 Programming from the ground up by Herbert Schildt (IMO one of the best books I've bought on windows programming)

Edited by - Steven on August 5, 2000 5:46:08 AM

I''d like to avoid Common Dialouge Boxes if possible ...

I''m still very pissed that findfirst and findnext don''t work with MSVC...

Does anybody know a custom library that might work?

Or could anybody confirm that the code segment offered by Steven for the Windows File data structure works... could anybody provide some quick code on how to use the code to print the names of the files it finds? (I hate working with windows and its data structures and routines... DOS is so much easier)

Thanks!

- Goblin
"A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

I just noticed as well a reference to findfirst and findnext in "io.h" rather than in "dir.h" and "_defs.h" as I had originally thought (maybe it''s different for Borland and MSVC?).

If the findfirst and findnext in io.h works with MSVC, could somebody give a simple example of its use? Other wise look to the above post. :]

Thanks.

- Goblin
"A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

Anybody?

- Goblin
"A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

Ok, this is a quick but tested code sample of using _findfirst and _findnext for you. It's done with MSVC 4 but this shouldn't have changed much if any in more recent versions.
#include
#include
#include

extern int errno;

int main()
{
long findhandle;
struct _finddata_t filedata;

/* see if we can find a first one
notice the *.* search pattern can be made into any appropriate wildcard */
if ((findhandle = _findfirst("*.*", &filedata)) == -1)
// didn't find one, bail
return 1;
else
cout << filedata.name << endl;

// we've got a valid pattern, let's see if there's any others
while (errno != ENOENT)
{
_findnext(findhandle, &filedata);
if (errno != ENOENT)
cout << filedata.name << endl;
}
return 0;
}

Edited by - Belandrew on August 8, 2000 3:06:18 PM

Thank you, thank you, thank you...

Though may I ask what the #includes are?

I would assume io.h, iostream.h, but I really don''t know what the other one might be...

Heh, kind of necessary to get the code working, thanks.

:]

- Goblin
"A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

Heh, ya, that got butchered somewhere along the lines.
You''re right on the 2 guesses, the 3rd is just errno.h which has the various error number defines (ie for ENOENT, which is error no entry)