|
I store the file path returned by CFileDialog into a database table and neither opened or modified.
The exception, however, is thrown when a query is executed in another table and in another CDialog, with no relations with the CDialog where CFileDialog has been executed.
I've even tried to compile with #define _WIN32_WINNT 0x500 and CFileDialog allocated on heap and when "delete dlg" is called, an exception is thrown immediatly.
It seems CFileDialog/GetOpenFileName has some weird behaviours. Searching around the web no solution i've applied has worked.
|
|
|
|
|
make the definition like that:
#define _WIN32_WINNT 0x0400
In CommDlg.h you can view this:
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
CFileDialog doesnt expect an OPENFILENAME this big.
|
|
|
|
|
so
Nyarlatotep wrote: CFileDialog dlg( TRUE, "jpg", NULL, OFN_OVERWRITEPROMPT|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST, szFilter, this );
if( dlg.DoModal() != IDOK )
{
return;
}
does not cause a problem if cancel is pressed but does cause a problem if you press ok right? I suspect that the problem lies in the code beyond this call. Pressing cancel will cause a 'return' to execute, pressing ok will cause what ever code is after this to execute...
<br />
CFileDialog dlg( TRUE, "jpg", NULL, OFN_OVERWRITEPROMPT|OFN_HIDEREADONLY|OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST, szFilter, this );<br />
if( dlg.DoModal() != IDOK )<br />
{<br />
return;<br />
}<br />
<br />
...WHAT CODE IS HERE?<br />
cje
|
|
|
|
|
Oh i've commented out the code which is executed when the OK button is pressed. It doesn't solve ...
|
|
|
|
|
Have you tried catching the exception and outputting the error message?
Mark
|
|
|
|
|
The instruction which throws the exception (in another CDialog, different from those where CFileDialog is invoked) is a execution of a SQLite query. The exception catched doesn't explain very much: only a error code of 1, which in SQLite is generic.
|
|
|
|
|
Nyarlatotep wrote: The exception catched doesn't explain very much: only a error code of 1, which in SQLite is generic.
Well, that's helpful 
I would first make sure that no string operations have overruns.
I've never used SQLite, but maybe a previous query is still open that needs to be closed?
|
|
|
|
|
Neither of those events would occur.
1) User clickx on button A
2) Dialog A is opened and the database is opened in the OnInitDialog and a query is executed (and closed)
3) A browse button is pressed in Dialog A and CFileDialog (or GetOpenFileName API) is invoked to browse for a file
4) When Dialog A is closed data is saved into the db with an update (but the problems occurs even if no update is done)
5) User now clicks on button B
6) Dialog B is opened and the database is opened in the OnInitDialog and a query is executed ==> Exception
if point 3) is not executed (and file is not selected) no problems arise ...
I'm getting crazy ... 
|
|
|
|
|
hmm...It's hard to tell what's happening - if it's a after-effect of a previous problem or an actual problem at the query.
All I can think of based on what I've read so far...
Divide and conquer! Comment out dynamically-created queries and test with static queries you
know should work. Use a static sring instead of the returned string from CFileDialog.
You should be able to narrow it down
|
|
|
|
|
Now i'm tring directly with the GetOpenFileName() and a static buffer (char strPath[MAX_PATH]) for the OPENFILENAME. No MFC, therefore.
But it doesn't solve ...
Tried to use the OPENFILENAME_NT4 structure and the OPENFILENAME_SIZE_VERSION_400 structure size (in MSDN they say MFC42 application compiled with _WIN32_WINNT set to 0x0500 should use this structure to avoid avoid heap corruption).
Nothing ...
|
|
|
|
|
I meant ignore whatever the fileopen dialog returns. Call the dialog (DoModal(), etc) but instead
of using the result just pass a const string to the query ("C:\\test.jpg" or whatever).
If it works then you know the problem is something fileopen dialog related. If it still
doesn't work then the problem is elsewhere, maybe query related, maybe related to some memory
corruption that occured somewhere else, etc...
|
|
|
|
|
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...
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Mark Salsbery wrote: In what version(s).
VS6. It has to do with the OPENFILENAME structure 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.
*EDIT* It has been fixed in later versions.
|
|
|
|
|
I've avoided CFileDialog and used the GetOpenFileName API.
So no problem with destructors and CFileDialog but the original problem still occurs ...
|
|
|
|
|
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.
|
|
|
|
|
Think of the fact that GetOpenFileName changes current directory. So after using common dialogs it should be checked what file SQLite functions work with.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
