|
First of all you should really check the return value of ::GetOpenFileName() to see whether the operation was successful or not.
I think the easiest way to get the filenames of the selected files would be to parse the ofn.lpstrFile string.
Something like this:
if( ::GetOpenFileName( &ofn ) )
{
char* pFilename = ofn.lpstrFile;
while( *pFilename++ );
if( !*pFilename )
{
TRACE( "A single file was selected: %s\n", ofn.lpstrFile );
}
else
{
TRACE( "Multilpe files were selected:\n" );
while( *pFilename )
{
TRACE( "%s\\%s\n", ofn.lpstrFile, pFilename );
while( *pFilename++ );
}
}
}
You should be able to just copy/paste the snippet above.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
I have finding the such a same code from the MSDN.
is below.
<code>
WIN32_FIND_DATA FindFileData;
HANDLE hFind = INVALID_HANDLE_VALUE;
char DirSpec[MAX_PATH];
DWORD dwError;
printf ("Target directory is %s.\n", argv[1]);
strncpy (DirSpec, argv[1], strlen(argv[1])+1);
strncat (DirSpec, "\\*", 3);
hFind = FindFirstFile(DirSpec, &FindFileData);
if (hFind == INVALID_HANDLE_VALUE)
{
printf ("Invalid file handle. Error is %u\n", GetLastError());
return (-1);
}
else
{
printf ("First file name is %s\n", FindFileData.cFileName);
while (FindNextFile(hFind, &FindFileData) != 0)
{
printf ("Next file name is %s\n", FindFileData.cFileName);
}
dwError = GetLastError();
FindClose(hFind);
if (dwError != ERROR_NO_MORE_FILES)
{
printf ("FindNextFile error. Error is %u\n", dwError);
return (-1);
}
}
return (0);
i will follow your guidline.
thanks
Amit
|
|
|
|
|
its only give the current folder path not given the number of files.
thats why i am confused for last 4 hours .
its only give the current folder name path no number of files.
like
e.g.
D:\test\testfolder1(this is according Mr.Nibu babu thomas) it gives the current path,last folder in which the files stored.
i ask you one question when we open the file dialog and selecting multiple files we can select files
with ctr+ and dipslay it in the file name with double quotes like
File Name :<code>"x.wmv""y.wmv""z.wmv"</code> open
type:*.wmv
then it should come in the WIN32_FIND_DATA variable why it is not come ?
i have add D:\test\testfolder1\* in my sample but its not work.
amit
|
|
|
|
|
Haven't you tried the code I posted in my previous reply?
I thought you would since you said you would "follow my guideline"...
Use the code I sent. It parses the OPENFILENAME::lpstrFile string and it works. Just do whatever you have to do with the filenames at the TRACE locations in my code.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
ya I had try it.but when select number of files from the dialog and select ok . at that time
in (char*) ofn.lpstrFile; contain value c:\test\test1 no any files or serries of file name.when i debug it in pFileName it start with c then : the \ etc.. given the series of chars.
mean when i select it is not gives selected files but given the current folder in which selected files.
I follow your code and the above is result.i am also try with other one let see what happen??? 
Amit
|
|
|
|
|
amitmistry_petlad wrote: I follow your code and the above is result
Of course since the debug window only displays the contents of a string until it reaches the "terminating" NULL char. The data that is returned by ::GetOpenFileName() doesn't end there. Bring it up in the memory window and have a look at it there.
If you select multiple files in the open file dialog box, the OPENFILENAME::lpstrFile string will be built up in a similar way as you've built your filter string, as WalderMort told you earlier.
Set a breakpoint at the TRACE statement that looks like
TRACE( "%s\\%s\n", ofn.lpstrFile, pFilename ); in my code and debug it. When the execution stops at the breakpoint, have a look at the strings pointed to by both ofn.lpstrFile and pFilename. At this point ofn.lpstrFile points to a string containing the folder path and pFilename points to a string that contains the first filename that the user has selected. The TRACE call puts the parts together and print the complete file path in the debug window. On the next iteration ofn.lpstrFile still contains the folder path, but pFilename points to the second filename.
Just step through it while watching the variable contents and you'll get the picture.
I hope you have read this[^] MSDN article about the OPENFILENAME structure. In case you haven't, it's highly recommended. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
should i have to include trace.h header for tracing because it gives error Error 62 error C3861: 'TRACE': identifier not found d:\projects\drmclient\utils.cpp 43
how can i enable trace for my application.
|
|
|
|
|
I didn't know you were building without MFC.
No big deal, use ::OutputDebugString() instead, like this:
if( ::GetOpenFileName( &ofn ) )
{
char* pFilename = ofn.lpstrFile;
while( *pFilename++ );
if( !*pFilename )
{
std::string output = ofn.lpstrFile;
output += "\n";
::OutputDebugString( output.c_str() );
}
else
{
::OutputDebugString( "Multiple files were selected:\n" );
while( *pFilename )
{
std::string output = ofn.lpstrFile;
output += "\\";
output += pFilename;
output += "\n";
::OutputDebugString( output.c_str() );
while( *pFilename++ );
}
}
}
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
The output saying different. its give me ??????? question mark string only in the output window.
and i also put messagebox but didnt getting proper output.It dispaly sqarebox(like unicode char).
|
|
|
|
|
amitmistry_petlad wrote: It dispaly sqarebox(like unicode char)
That sounds like a unicode mixup and it looks as the reason is that you're using the datatype string which is a typedef of std::basic_string<char>. Use std::basic_string<WCHAR> instead.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
no its not given the file name which i have selected from dialog .its given the single character
of that path in the messagebox. when the path completed its terminate.
so ultimately i haven't found any selected file in the string output.
Amit
|
|
|
|
|
Run the application and break at the same location as I mentioned earlier, i.e. where the last TRACE used to be.
Bring up the memory window[^] and have it displaying the memory that surrounds the data for ofn.lpstrFile. What does it look like (write exactly how it looks)? Can you sense a pattern in the data?
I think you should also post how your code looks like at this point.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
as per our logn communication can you explain me one thing,
the output string give the path. its not finding any file after at the end of the path as in your code. is it really in buffer(files)? and if it is then why our control has directly switch over to the first selected file after current folder rather than traversing in the path string.
Amit
|
|
|
|
|
I don't think I understand your question at all.
Have you understood that the data pointed to by ofn.lpstrFile is not really a string, but rather a multitude of strings seperated by a NULL character where the first is the folder path?
As an example:
Let's say you open the file dialog and browse to a directory "C:\MyDocs" and select three files, "File.txt", "File2.txt" and "File3.log". The data pointed to by ofn.lpstrFile will look like this "C:\MyDocs\0File1.txt\0File2.txt\0File3.log\0\0" which means that if you treat ofn.lpstrFile as a string it will only display "C:\MyDocs" and no file names since strings are "zero-terminated".
The while( *pFilename++ ); statement in my code increments the pFilename pointer until it reaches a "\0" and then increments the pointer once so that dereferencing the pointer will give the first character of the next filename. Or if you treat it as a string it will be the filename. If that character is "\0" as well, then the last selected filename has been handled and that's what the outer while-loop is checking for in my code.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Let's say you open the file dialog and browse to a directory "C:\MyDocs" and select three files, "File.txt", "File2.txt" and "File3.log". The data pointed to by ofn.lpstrFile will look like this "C:\MyDocs\0File1.txt\0File2.txt\0File3.log\0\0" which means that if you treat ofn.lpstrFile as a string it will only display "C:\MyDocs" and no file names since strings are "zero-terminated".
i seem that when i try to print file name i got the each char less from the starting.
like suppose "C:\MyDocs\0File1.txt\0File2.txt\0File3.log\0\0"
The messagebox series follows.
at first time :\MyDocs
then \MyDocs
then yDocs
then Docs
then ocs
then cs etc.
then I assume that loop comes out after the folders last char,but as you explained it will vartually count files which is in buffer that's ok. then why i got the ???????? mark as still unable to
understand.
The means of that files do not come in the buffer or i am some where wrong??
Amit
|
|
|
|
|
|
amitmistry_petlad wrote: Roger Stoltz wrote:
Bring up the memory window[^]
Please:
http://en.wikipedia.org/wiki/Image:Outputwindow.GIF [^]
Why do you show me an image of the output window when I explicitly ask for the memory window? I even provided a link so you wouldn't misinterpret what I meant.
I also requested that you post the code at this point and you haven't done so either.
This means I cannot help you and I suggest you spend some time to get familiar with the development environment.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: When you allow selecting a multitude of files in the file dialog, i.e. setting the OFN_ALLOWMULTISELECT flag, you should use ::FindFirstFile() / ::FindNextFile()...
Why? Exactly how does the FindFirstFile()/FindNextFile() pair parse through NULL-separated filenames?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
 hi,
Can anybody tell me,What is the basic difference between mfc and win32 and also how it differs by it's application????
Thanks in advance
Siddharth
|
|
|
|
|
Basically, MFC's are wrapper classes around the win32 API. Meaning that it is much more faster to develop applications using MFC instead of win32 (but you lose of course in some flexibility).
|
|
|
|
|
MFC -> VC++ wrapping Win32
Win32 -> C APIs only
|
|
|
|
|
toxcct wrote: MFC -> C++ wrapping Win32
You might want to qualify that with:
MFC -> VC++ wrapping Win32
Else some pedantic poster will come along and scorn you for it.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
oh my ! all fixed David, Thx
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
