CFileDialog
-
yes I've tried to ignore the GetOpenFileName() result and using a static string but it doesn't solve. Perhaps I have to follow another way but to me it seems the problem resides in the GetOpenFileName() API, whichever it is ...
If you do JUST this...
const char *szFilter = "JPG images (*.jpg)|*.jpg||";
CFileDialog dlg( TRUE, "jpg", NULL, OFN_FILEMUSTEXIST| OFN_HIDEREADONLY, szFilter, this );
if( dlg.DoModal() != IDOK )
{
return;
}static char szTest = "C:\\test.jpg";
...do the query using szTest
...and it still doesn't work then the problem has nothing to do with the openfile dialog. The common dialog (and its associated MFC wrapper class) has been around quite a while with no "weirdness". It really sounds like the problem is elsewhere...
-
If you do JUST this...
const char *szFilter = "JPG images (*.jpg)|*.jpg||";
CFileDialog dlg( TRUE, "jpg", NULL, OFN_FILEMUSTEXIST| OFN_HIDEREADONLY, szFilter, this );
if( dlg.DoModal() != IDOK )
{
return;
}static char szTest = "C:\\test.jpg";
...do the query using szTest
...and it still doesn't work then the problem has nothing to do with the openfile dialog. The common dialog (and its associated MFC wrapper class) has been around quite a while with no "weirdness". It really sounds like the problem is elsewhere...
It could be. (even if, searching around, some 'weirdness' for the MFC CFileDialog wrapper class has been found). However, I've used this functions thousand of times with no problems, in the past. May be some system DLL has been replaced by some software ?
-
It could be. (even if, searching around, some 'weirdness' for the MFC CFileDialog wrapper class has been found). However, I've used this functions thousand of times with no problems, in the past. May be some system DLL has been replaced by some software ?
Nyarlatotep wrote:
May be some system DLL has been replaced by some software ?
I'm sure that's it. Couldn't possibly be a problem elsewhere in your code :rolleyes:
-
If you do JUST this...
const char *szFilter = "JPG images (*.jpg)|*.jpg||";
CFileDialog dlg( TRUE, "jpg", NULL, OFN_FILEMUSTEXIST| OFN_HIDEREADONLY, szFilter, this );
if( dlg.DoModal() != IDOK )
{
return;
}static char szTest = "C:\\test.jpg";
...do the query using szTest
...and it still doesn't work then the problem has nothing to do with the openfile dialog. The common dialog (and its associated MFC wrapper class) has been around quite a while with no "weirdness". It really sounds like the problem is elsewhere...
const char *szFilter = "Excel Worksheet Files (*.xls)|*.xls||"; CFileDialog dlg( TRUE, "xls", NULL, OFN_FILEMUSTEXIST|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST, szFilter, this ); if( dlg.DoModal() != IDOK ) { return; } Tried this code (compiling with /D_WIN32_WINNT=0x500) and when CFileDialog destructor is invoked an exception occurs.
-
const char *szFilter = "Excel Worksheet Files (*.xls)|*.xls||"; CFileDialog dlg( TRUE, "xls", NULL, OFN_FILEMUSTEXIST|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST, szFilter, this ); if( dlg.DoModal() != IDOK ) { return; } Tried this code (compiling with /D_WIN32_WINNT=0x500) and when CFileDialog destructor is invoked an exception occurs.
you are calling this from what function? I get no errors with your code and _WIN32_WINNT=0x500. I'm on VS 2003, MFC 7.10 -- modified at 16:13 Monday 27th November, 2006
-
const char *szFilter = "Excel Worksheet Files (*.xls)|*.xls||"; CFileDialog dlg( TRUE, "xls", NULL, OFN_FILEMUSTEXIST|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST, szFilter, this ); if( dlg.DoModal() != IDOK ) { return; } Tried this code (compiling with /D_WIN32_WINNT=0x500) and when CFileDialog destructor is invoked an exception occurs.
Nyarlatotep wrote:
...when CFileDialog destructor is invoked an exception occurs.
This is a known issue.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
Nyarlatotep wrote:
...when CFileDialog destructor is invoked an exception occurs.
This is a known issue.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
In what version(s). Do you have a link? :) Thanks, mark
-
In what version(s). Do you have a link? :) Thanks, mark
Mark Salsbery wrote:
In what version(s).
VS6. It has to do with the
OPENFILENAMEstructure that MFC was compiled with. I'm not sure if it has been fixed in newer versions. Here is a semi-related article. There's also the possibility that Adobe Reader is causing the problem. A similar thread.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
Mark Salsbery wrote:
In what version(s).
VS6. It has to do with the
OPENFILENAMEstructure that MFC was compiled with. I'm not sure if it has been fixed in newer versions. Here is a semi-related article. There's also the possibility that Adobe Reader is causing the problem. A similar thread.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
Thanks. Noted for future reference :)
DavidCrow wrote:
There's also the possibility that Adobe Reader is causing the problem.
:doh:
*EDIT* It has been fixed in later versions. -
Mark Salsbery wrote:
In what version(s).
VS6. It has to do with the
OPENFILENAMEstructure that MFC was compiled with. I'm not sure if it has been fixed in newer versions. Here is a semi-related article. There's also the possibility that Adobe Reader is causing the problem. A similar thread.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
I've avoided CFileDialog and used the GetOpenFileName API. So no problem with destructors and CFileDialog but the original problem still occurs ...
-
My application uses CFileDialog to select a file to work with. It seems to work well (the file is selected and returned) but when I execute other part of the application, an exception occurs (always in the same instruction: a query execution) No problems arise if CFileDialog DoModal is not called or even if it is called but no file is selected (cancel button) First I've tried to understand the problem, compiling with the SDK and using even "#define _WIN32_WINNT 0x500" and using CFileDialog either on stack and heap, but with no results. At the end I've used the GetOpenFileName() API but it doesn't solve. const char *szFilter = "JPG images (*.jpg)|*.jpg||"; CFileDialog dlg( TRUE, "jpg", NULL, OFN_OVERWRITEPROMPT|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST, szFilter, this ); if( dlg.DoModal() != IDOK ) { return; } I use VC++ 6.0 SP6 with PDSK Feb 2003 on XP Professional SP2 Some tips ?
-
Hi, I am not getting any error with your code. Its working perfect. Do you have Adobe Acrobat Reader 7.0 or later in your system. If so, uninstall the Reader and try again. Best Regards, Suman
I've Acrobat Reader 5.1 (7.0 is too heavy :) ). I have given the application to a friend of mine, running on W2000: same error. I have used the API GetOpenFileName (in every 'taste') instead of MFC CFileDialog obtaining the same problem. I've build a brand new MFC dialog application with no other code than a button which open a dialog and does a fake SQLite query and a button which runs GetOpenFileName, to be sure no other code could cause the problem in conjunction with GetOpenFileName: same error. Summary: when a common dialog is shown (Open file dialog, File save dialog, Printer dialog), the next call to sqlite3_prepare() (which compile a SQLite query) fails with an exception. Naturally I've used either common dialog+SQLite many times in the past with no such problems. To get around this problem, I've have decided to put the Common Dialog call into a little application and call that from the main application which some kind of interprocess communication.
-
I've Acrobat Reader 5.1 (7.0 is too heavy :) ). I have given the application to a friend of mine, running on W2000: same error. I have used the API GetOpenFileName (in every 'taste') instead of MFC CFileDialog obtaining the same problem. I've build a brand new MFC dialog application with no other code than a button which open a dialog and does a fake SQLite query and a button which runs GetOpenFileName, to be sure no other code could cause the problem in conjunction with GetOpenFileName: same error. Summary: when a common dialog is shown (Open file dialog, File save dialog, Printer dialog), the next call to sqlite3_prepare() (which compile a SQLite query) fails with an exception. Naturally I've used either common dialog+SQLite many times in the past with no such problems. To get around this problem, I've have decided to put the Common Dialog call into a little application and call that from the main application which some kind of interprocess communication.
-
Think of the fact that GetOpenFileName changes current directory. So after using common dialogs it should be checked what file SQLite functions work with.
This could really be the answer ! But I should exhume the code wherever it is now, after three years. However this seems an useful clue. Thanks. :)