Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Trouble with using FindFirstFile in MFC app

Posted on 1998-05-21
Medium Priority
Last Modified: 2013-11-20
I have a dialog based application. From the OnInitDialog() I want to build a list of a specific kind of files and update my combo box on the dialog. To get a listing of those kind of files from the hard disk, I call the Win32 functions FindFirstFile and FindNextFile. I had successfully tested these functions from a console app and they seemed to be fine, but my dialog app cannot execute the FindFirstFile and I get an unhandeled exception in NTDLL.DLL for an access violation. Another information that might be helpful is the prototype of FindFirstFile is as:
My calling sequence is as follows:
char myFile="C:\\*.ppp";  // for example
LPWIN32_FIND_DATA lpFindFileData;
HANDLE myHandle;

myHandle = FindFirstFile (myFile, lpFindFileData);

       Another question I have is if I can use normal C based char string pointers in place of LPCTSTRS?
Question by:syedm
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2

Accepted Solution

tma050898 earned 600 total points
ID: 1313715
Here's an example of how I've done this in an MFC application.

WIN32_FIND_DATA findData;                                      
CString strFileMask = "CommSvr*.DLL";

char szCurrentDirectory[CHAR_MAX];
GetCurrentDirectory(sizeof(szCurrentDirectory), szCurrentDirectory);

ZeroMemory(&findData, sizeof(findData));
hFile = FindFirstFile(strFileMask, &findData);
  if ((findData.dwFileAttributes & FILE_ATTRIBUTE_NORMAL) ||
  (findData.dwFileAttributes & FILE_ATTRIBUTE_ARCHIVE))
   TRACE1("*** Found '%s'\n", findData.cFileName);
 } while (FindNextFile(hFile, &findData));


LVL 10

Expert Comment

ID: 1313716
You can do this a little simpler with the CFileFind class.  ie:

    CFileFind finder;
    BOOL bWorking = finder.FindFile("C:\\*.ppp");
    while (bWorking) {
        bWorking = finder.FindNextFile();
        cout << (LPCTSTR) finder.GetFileName() << endl;

this is much simpler than working directly with the API.

BTW:tma .. why do you get the current directory in the code above.  This does not seem to be required (or used).


Expert Comment

ID: 1313717

The code above was code taken from an actual application with a lot of my application-specific code cut out. I just missed the declaration of that variable. It has no bearing on this code now.


What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

LVL 10

Expert Comment

ID: 1313718
I thought as much .. happens to me all the time when I quote extracts from my working code .. either I miss something I needed or put in something I don't.

Just thought I'd point that out so that syendm would realise this also an not think that this was required for some mysterious reason.

> Another question I have is if I can use normal C based
> char string pointers in place of LPCTSTRS?

Yes .. as long as you are working not working with UniCode.  The TCHAR and xxxTSTR types depend on the unicode settings.  When using unicode, these correspond to wide (16-bit) characters.  Otherwise they a 8-bit chars.

However, generally when working with windows, use TCHAR and LPTSTR etc for all your 'C' characters and strings (unless you want to always use 8-bit characters)


Author Comment

ID: 1313719
Actually I figured out the second method yu pointed out, namely using the CFindClass class. Also before that I played around with placing FindFirstFile and FindNextFile at different places in the application and it always behaved differently. For instance it never worked in the OnInitDialog(). Next I placed a button on the dialog and moved these to the button handler and it always worked. But I needed this at the time dialog was initialized, so I tried using these API's within the App constructor (the idea was that I will store the names within a linked list or something and look it up when the InitDialog() happens). With this approach I had FindFirstFile working but the FindNextFile failed!!! Lastly I ended up using CFindFile within the App constructor and it seemed to work perfectly.

    I guess the bottom line is that with MFC yu get a lot of functionality but yu also are disadvantaged by the fact that a LOT is happening behind the veils of MFC and if something does not work as yu expected yu end up using a lot of trial/error methods.
LVL 10

Expert Comment

ID: 1313720
BTW: CFindFile was my suggestion, not tma's


Expert Comment

ID: 1313721

Did you use the code above in the OnInitDialog and it failed??? I'm just curious because that exact code is located in my OnInitDialog and it has always worked perfectly.



Author Comment

ID: 1313722
Ronslay, I'm sorry, yu'r right.

   Yeah, it was pretty much similar to your code, except that it was not getting the current directory and that it was structured in form of
while() { ... }
rather than
do { .... } while ();
Also the code using CFindFile is in the first form, although after exiting from the while loop it again gets the file name using CFindFile::GetFileName().
This code is also a portion of App constructor, I did not get a chance to try CFindFile in OnInitDialog.


Expert Comment

ID: 1313723

If the CFindFile works, that's fine as long as you find something that works for you.

My only concern was that you indicated that the FindFirstFile wasn't working for you and I know that the code snippet I gave is in fact working. As a matter of fact, it's working in the IBM WorldBook Multimedia Encyclopedia product right now ;) Therefore, if you want to use the FindFirstFile and isn't working in your OnInitDialog or you just want to know why it doesn't work in OnInitDialog, post the code and I'll take a look at it.


Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This is to be the first in a series of articles demonstrating the development of a complete windows based application using the MFC classes.  I’ll try to keep each article focused on one (or a couple) of the tasks that one may meet.   Introductio…
Introduction: Dialogs (2) modeless dialog and a worker thread.  Handling data shared between threads.  Recursive functions. Continuing from the tenth article about sudoku.   Last article we worked with a modal dialog to help maintain informat…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA:…

721 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question