-
CFileDialog crash in Platform SDK
I have installed Platform SDK Windows Server 2003 (I work in VS 6.0 on WinXP) and I have a problem with CFileDialog.
This code
Code:
void CFileTestView::OnViewFile()
{
CFileDialog dlg(TRUE);
dlg.DoModal();
}
worked just fine before defining _WIN32_WINNT, which I need to use different functions and constants. Now, when I define it
Code:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif
my code just crashes in ~CFileDialog (when dlg does out of scope and is destroyed). Since m_ofn member of CFileDialog depends on this _WIN32_WINT:
Code:
typedef struct tagOFN {
// ...
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME
I rewrote the code this way:
Code:
void CFileTestView::OnViewFile()
{
CFileDialog dlg(TRUE);
#if (_WIN32_WINNT >= 0x0500)
dlg.m_ofn.pvReserved = NULL;
dlg.m_ofn.dwReserved = 0;
dlg.m_ofn.FlagsEx = 0;
#endif
dlg.DoModal();
}
but I still get a first-chance exception in FileTest.Exe (KERNEL32.dll) 0xC0000005: Access Violation (the usual stuff).
Any ideas? Thanks!
-
Re: CFileDialog crash in Platform SDK
Yeah. It's a bug in Windows, brought out by declaring WINVER equal to or greater than 500. I've had the same problem in VC++ 6.0.
You can get around it by declaring your CFileDialog object on the stack, eg.:
Code:
{
CFileDialog *pFD = new CFileDialog( TRUE );
pFD->DoModal();
// etc.
// etc.
delete pFD;
}
-
Re: CFileDialog crash in Platform SDK
Thanks TSYS. It worked. :thumb:
Now I have to go back in this 200 KLOC project and replace dozens of CFileDialog with CFileDialog*... :mad:
-
Re: CFileDialog crash in Platform SDK
Now, there's a real bad news: if I derive CFileDialog I still have that problem:
Code:
CMyFileDialog : public CFileDialog
{
// all the stuff
};
Code:
{
CMyFileDialog *pFD = new CMyFileDialog( TRUE );
pFD->DoModal();
delete pFD; // first-chance exception...
}
-
Re: CFileDialog crash in Platform SDK
Haven't run into that, but then I rarely derive from CFileDialog. You may have to lift the source code from Microsoft and fix the bug yourself.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by cilu
Now, there's a real bad news: if I derive CFileDialog I still have that problem:
Code:
CMyFileDialog : public CFileDialog
{
// all the stuff
};
Code:
{
CMyFileDialog *pFD = new CMyFileDialog( TRUE );
pFD->DoModal();
delete pFD; // first-chance exception...
}
After you call DoModal, try calling other method - if it fails, you need to remove the 'delete'. WHY?
Well, that just a guess/suggestion - it may be that CFileDialog, when allocated in heap, might be calling "delete this" in it's PostNCDestroy. Just like Frame and Views - I know frame/views are always allocated in heap not in stack. But this may be the case...
-
Re: CFileDialog crash in Platform SDK
No, that's not the case. I can call any method after DoModal() and it works. It only crashes at delete.
-
Re: CFileDialog crash in Platform SDK
All this seems to be problem with 'pvReserved' data member. Try setting it to NULL before you delete. You may also try IsBadWritePtr/IsBadReadPtr on 'pvReserved' and/or to dialog object itself.
-
Re: CFileDialog crash in Platform SDK
If you look at my first post you see that I already set pvReserved to NULL and dwReserved to 0. After calling DoModal(), they are unchanged, NULL and 0. And I also set lStructSize = sizeof(OPENFILENAME).
Code:
dlg->m_ofn.lStructSize = sizeof (OPENFILENAME);
-
Re: CFileDialog crash in Platform SDK
I suggest you to find out the solution in stack version of your class, because making changes this way would increase problems. For the time being, it is better to "ignore" something and move forward...
-
Re: CFileDialog crash in Platform SDK
I am also having the same error.... :cry: :(
Code:
CFileDialog f(true,NULL,NULL,OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST|OFN_HIDEREADONLY,
"...",
this);
if(f.DoModal() != IDOK)
return; // HERE
-
Re: CFileDialog crash in Platform SDK
From what I see in MSDN, 0x0501 means Windows XP and Windows .NET Server. Perhaps you need a different value for 2003?
EDIT: I see now you've mentioned 2003.
-
Re: CFileDialog crash in Platform SDK
MFC70 has 7th parameter to give the sizeof OPENFILENAME structure, which does not exist in MFC42 (6.0v). We can set it as:
Code:
f.m_ofn.lStructSize = sizeof(OPENFILENAME);
While debugging this thing, I found that 'lStructSize' is 76, which when the above code comes, becomes 88. I have defined
Code:
#define _WIN32_WINNT 0x500
in stdafx.h (before ALL headers).
Instead of this CFileDialog is compiled using OLD value of _WIN32_WINNT, and my code is compiled using new value (88 shows!).
WHY??
-
Re: CFileDialog crash in Platform SDK
Worth mentioning that I am using this thing, so that new-style dialog box (History, My computer, Network Places) appear on my dialog. I got success in that, but not AV problem!
-
Re: CFileDialog crash in Platform SDK
I think your problem might have something to do with the precompiled headers.Try defininning that value in the project settings ( ++ options) and not in your code.
-
Re: CFileDialog crash in Platform SDK
You are right and I thought so. But StdAfx.h is PCH in my case (as usual). I also Rebuilt the project, but problem remains the same: When object ceases, it causes AV. I tried: stack allocation, heap, static instance and global instance -- ALL fails when object destroys. The problem is at line 121 in Afx.INL:
Code:
_AFX_INLINE CStringData* CString::GetData() const
{ ASSERT(m_pchData != NULL); return ((CStringData*)m_pchData)-1; }
-
Re: CFileDialog crash in Platform SDK
The probable problem behind this I found is mis-matched order of Libray and Include files in "Directories". Either platform SDK library and include files come first or VC98/Include.. should.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by Ajay Vijay
I am also having the same error.... :cry: :(
No kidding... Now we are two :D
It's enought to do this:
Code:
CFileDialog f(FALSE);
And you get the first-chance exception.
Quote:
MFC70 has 7th parameter to give the sizeof OPENFILENAME structure, which does not exist in MFC42 (6.0v). We can set it as:
Well, I know, I read the MSDN too, but unfortunatelly I work on VS 6.0 and CFileDialog doesn't have the 7th DWORD paramether. :sick:
Quote:
The problem is at line 121 in Afx.INL:
Yes, it crashes there.
Quote:
Originally Posted by padex
From what I see in MSDN, 0x0501 means Windows XP and Windows .NET Server. Perhaps you need a different value for 2003?
I have Platform SDK for Windows Server 2003 which is supposed to work with all Windows OS. Platform SDK XP works only with WinXP.
Quote:
While debugging this thing, I found that 'lStructSize' is 76, which when the above code comes, becomes 88. I have defined in stdafx.h (before ALL headers).
Instead of this CFileDialog is compiled using OLD value of _WIN32_WINNT, and my code is compiled using new value (88 shows!).
WHY??
sizeof(OPENFILENAME) == 76 is _WIN32_WINNT is not defined or is lower than 0x500 and 88 otherwise.
Code:
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
I have also this problem with includes. Though I put SDK folders (include, lib, bin and src) before the default folders from VS6.0 at Options, Directories if I step into the constructor it goes to the VC98\MFC\SRC\DLGFILE.cpp :sick: so it doesn't use the CFileDialog from Platform SDK...
-
Re: CFileDialog crash in Platform SDK
But I got the solution by:
* Setting the PlatformSDK include/source/libs before VC default dirs.
* Setting _WIN32_WINNT to 0x500
* Setting the lStructSize to 88 (I need to revise this, dynamically).
Now it does not crashes!
-
Re: CFileDialog crash in Platform SDK
My settings are:
lib
Code:
C:\PROGRAM FILES\MICROSOFT SDK\LIB
C:\Program Files\Microsoft Visual Studio\VC98\LIB
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB
includes
Code:
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
and my code crashes
Code:
void CFileTestView::OnViewFile()
{
CFileDialog *dlg = new CFileDialog(FALSE);
dlg->m_ofn.lStructSize = sizeof(OPENFILENAME);
#if (_WIN32_WINNT >= 0x0500)
dlg->m_ofn.pvReserved = NULL;
dlg->m_ofn.dwReserved = 0;
dlg->m_ofn.FlagsEx = 0;
#endif
delete dlg; // crash at CString::GetData()
}
Now, did you try to derive CFileDialog?
Code:
class CMyFileDialog : public CFileDialog
{
DECLARE_DYNAMIC(CMyFileDialog)
public:
CMyFileDialog(BOOL bOpenFileDialog, // TRUE for FileOpen, FALSE for FileSaveAs
LPCTSTR lpszDefExt = NULL,
LPCTSTR lpszFileName = NULL,
DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
LPCTSTR lpszFilter = NULL,
CWnd* pParentWnd = NULL);
protected:
//{{AFX_MSG(CMyFileDialog)
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
Code:
void CFileTestView::OnViewFile()
{
CMyFileDialog *dlg = new CMyFileDialog(FALSE);
dlg->m_ofn.lStructSize = sizeof(OPENFILENAME);
#if (_WIN32_WINNT >= 0x0500)
dlg->m_ofn.pvReserved = NULL;
dlg->m_ofn.dwReserved = 0;
dlg->m_ofn.FlagsEx = 0;
#endif
delete dlg; // crash boom boom
}
-
Re: CFileDialog crash in Platform SDK
My settings are also same (it was not that, there was conflict and just after I resolved - it worked).
Well, I do NOT:
* Have Win2003 Platform SDK (I have the latest, but not W3K)
* Inherit CFileDialog class
Further, I used 0x500 as version. I think you should use 0x501 (as Win2003/XP is >=0x501).
I used "88" directly.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by Ajay Vijay
Further, I used 0x500 as version. I think you should use 0x501 (as Win2003/XP is >=0x501).
I used "88" directly.
I tried with 0x500 also, don't worry. As for that 88, well, it is irrelevant, since sizeof(OPENFILENAME) gives me 88 (as it is supposed).
Now, DO inherit CFileDialog and see what happens...
-
Re: CFileDialog crash in Platform SDK
It is working:
Code:
class CFileDialogEx : public CFileDialog
{
DECLARE_DYNAMIC(CFileDialogEx)
public:
CFileDialogEx(BOOL bOpenFileDialog, // TRUE for FileOpen, FALSE for FileSaveAs
LPCTSTR lpszDefExt = NULL,
LPCTSTR lpszFileName = NULL,
DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
LPCTSTR lpszFilter = NULL,
CWnd* pParentWnd = NULL): CFileDialog(bOpenFileDialog, lpszDefExt, lpszFileName,dwFlags, lpszFilter,pParentWnd)
{}
protected:
//{{AFX_MSG(CMyFileDialog)
//}}AFX_MSG
// DECLARE_MESSAGE_MAP()
};
IMPLEMENT_DYNAMIC(CFileDialogEx,CFileDialog)
Usage:
Code:
CFileDialogEx *f = new CFileDialogEx(true,NULL,NULL,OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST|OFN_HIDEREADONLY,
"MPEG-4 files (*.mp4)|*.mp4|SDP files (*.sdp)|*.sdp|All Files (*.*)|*.*||",
this);
OPENFILENAME &of=f->m_ofn;
of.lStructSize = sizeof (OPENFILENAME);
if(f->DoModal() != IDOK)
{
delete f;
return;
}
CString s=f->GetPathName();
-
Re: CFileDialog crash in Platform SDK
I hope you are not trying to trick me :D
Code:
CFileDialogEx *f = new CFileDialogEx(true,NULL,NULL,OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST|OFN_HIDEREADONLY,
"MPEG-4 files (*.mp4)|*.mp4|SDP files (*.sdp)|*.sdp|All Files (*.*)|*.*||",
this);
OPENFILENAME &of=f->m_ofn;
of.lStructSize = sizeof (OPENFILENAME);
if(f->DoModal() != IDOK)
{
delete f;
return;
}
CString s=f->GetPathName();
First, if you press Open you get memory leaks since you don't destroy f. When I put a
it crashes. Same thing happens if I press Cancel and it goes in the body of that if.
Second this
Code:
OPENFILENAME &of=f->m_ofn;
of.lStructSize = sizeof (OPENFILENAME);
is the same with
Code:
f->m_ofn.lStructSize = sizeof (OPENFILENAME);
So I don't really see the point of that reference.
-
Re: CFileDialog crash in Platform SDK
Quote:
...if you press Open you get memory leaks since you don't destroy f. When I put a
Nope! I just ommited the rest of code, there exist delete f after all processing with file-dialog object.
Quote:
So I don't really see the point of that reference.
I know there is no point regard to design of program, but only to make program code a quite bit shorter (similar to "With" as in VB ;) )
What I ommited from your side is message-map from derived class.
-
Re: CFileDialog crash in Platform SDK
Did you ever figure this out Cilu?
-
Re: CFileDialog crash in Platform SDK
No, I didn't. :blush: :sick: Still looking for help here. :o
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by TSYS
Yeah. It's a bug in Windows, brought out by declaring WINVER equal to or greater than 500. I've had the same problem in VC++ 6.0.
You can get around it by declaring your CFileDialog object on the stack, eg.:
Code:
{
CFileDialog *pFD = new CFileDialog( TRUE );
pFD->DoModal();
// etc.
// etc.
delete pFD;
}
What I don't understand is why this even solved a problem. It is no different than this:
Code:
{
CFileDialog pFD(TRUE);
pFD.DoModal();
}
Unless C++ or Windows has some magical powers, the two pieces of code are equivalent. Maybe there was another problem, and only by chance using "new" to create the object worked.
Regards,
Paul McKenzie
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by cilu
No, I didn't. :blush: :sick: Still looking for help here. :o
Try the Windows API GetOpenFileName(). That is how you will know if it's a generic Platform SDK problem, or a bug in the MFC CFileDialog class itself.
Regards,
Paul McKenzie
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by Paul McKenzie
What I don't understand is why this even solved a problem. It is no different than this:
Code:
{
CFileDialog *pFD = new CFileDialog( TRUE );
pFD->DoModal();
// etc.
// etc.
delete pFD;
}
Code:
{
CFileDialog pFD(TRUE);
pFD.DoModal();
}
Unless C++ or Windows has some magical powers, the two pieces of code are equivalent. Maybe there was another problem, and only by chance using "new" to create the object worked.
No, they are not equivalent. In the first case pFD is created on the heap, in the second case on the stack.
I shall try that GetOpenFileName() suggestion.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by cilu
No, they are not equivalent. In the first case pFD is created on the heap, in the second case on the stack.
The program should work the same way. Again, programatically, what is the difference? Operator new() or creating an object non-dynamically -- makes no difference. A constructor is called, a call to DoModal() is done, and then the destructor is called. This is for both examples. Operatror new creates an object on the free store, while the other doesn't. Whether the object is created on the heap or stack, it works the same way. The only difference is that you may run out of stack space if you didn't create your object dynamically, and the object is very large in size.
Regards,
Paul McKenzie
-
Re: CFileDialog crash in Platform SDK
I also used GetOpenFileName in between and it worked! It shows that there is no problem in PSDK - but with CFileDialog that couldnt work with new PSDK.
Finally, I would recommend seeing lStructSize member - before you assign sizeof() from YOUR code. I did see that CFileDialog ctor initializes it to 76 (whatever the macros defined!!), and then to 88 from our code!
-
Re: CFileDialog crash in Platform SDK
I think I figured out why CFileDialog doesn't work. As I've already said, I work on VS6.0 which links CFileDialog related code to COMMDLG.DLL. This is a DLL for the common dialogs. Now, Platform SDK redefines OPENFILENAME but there is no newer DLL for common dialogs in PSDK. The code is still linked with the old DLL which knows nothing about the three new members of that structure. So code crashing is not surprizing. In order to work I should rewrite the entire CFileDialog or probably use the specific DLL from a newer version, such as VS.NET.
-
Re: CFileDialog crash in Platform SDK
Does Network Places, My Computer ... appear on the left of dialog box?
I simply mean: can you launch new style dialog box that appears in >=Win2K?
-
Re: CFileDialog crash in Platform SDK
Yes, they apear, both with CFileDialog and GetOpenFileName(). With the later there is no first-chance exception. Only CFileDialog has problems.
-
CFileDialog crash due to _WIN32_WINNT >= 0x0500 - solution enclosed
I've had this same problem, and found the solution in the MSDN Magazine from August 2000.
Since I happened upon this thread (with recent posts) and no solution posted, I figured I'd post the link.
Here it is:
http://msdn.microsoft.com/msdnmag/is...c/default.aspx
If this link doesn't work, look for the article:
Windows 2000 File Dialog Revisited; Autocompletion and the ACTest Demo App
By Paul DiLascia
From the August 2000 MSDN Magazine, C++ Q&A.
What's amazing is that a bug found over 4 years ago wasn't fixed with a patch, or least a formal KB article post. Thanks, Microsoft.
- John
-
Re: CFileDialog crash in Platform SDK
Though I didn't know about that article, I knew about that solution from a project found on CodeProject. However, that was the thing I hoped I don't have to do, so now I know I have too. :o
Anyway, thanks for the link. It would probably help others.
-
Re: CFileDialog crash in Platform SDK
Yes, thanks for pointing that out. I don't think I'll try duplicating Microsoft code, though - that seems a recipe for instant disaster when the operating system gets upgraded.
I'll stick with using the "new" operator, and let the extra bytes languish on the stack.
This brings up a point that's bothered me for a while, though: How do you report a bug to Microsoft if you don't belong to MSDN? The last time I tried, they put a charge of over $200 on my credit card (which was refunded the same day, I hasten to add). Still, it was an off-putting experience, especially considering the cost if it turned out I had missed something important (yes, I have been known to do that).
-
Re: CFileDialog crash in Platform SDK
Well, to tell the truth, I didn't implement the MSDN "rewrite" either. I also hate to copy & paste MFC code since that is often asking for trouble down the line.
I just call the raw API function now. The MFC wrapper really isn't very useful anyhow, since the API function is so straight-forward.
Code:
CString SimplePickFile(CWnd *pWnd, LPCTSTR pszTitle)
{
OPENFILENAME ofn;
TCHAR pszFile[MAX_PATH*2];
_tcscpy(pszFile, _T("") );
memset( &ofn, 0, sizeof(ofn) );
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = pWnd ? pWnd->m_hWnd : GetActiveWindow();
ofn.lpstrFile = pszFile;
ofn.nMaxFile = sizeof(pszFile);
ofn.Flags = OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_NONETWORKBUTTON | OFN_FILEMUSTEXIST;
ofn.lpstrFilter = _T("All Files (*.*)\0*.*\0Executables (*.exe;*.ocx;*.dll)\0*.exe;*.ocx;*.dll\0");
ofn.lpstrTitle = pszTitle ? pszTitle : _T("Please select a file");
if (GetOpenFileName( &ofn ))
return pszFile;
else
return CString();
}
- John
-
Re: CFileDialog crash in Platform SDK
This problem IS fixed in VS70 and MFC70. The problem only happens when you are using VC6 and MFC4.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by donmesserli
This problem IS fixed in VS70 and MFC70. The problem only happens when you are using VC6 and MFC4.
Yes, I know... :sick:
-
Re: CFileDialog crash in Platform SDK
Please check whether ur system have installed Adobe Acrobat Reader 7.0 or later!! .If so, uninstall Adobe Reader and try again. coz I had the same problem and resolved by uninstalling Adobe Reader 7.0.
Thanks,
sabapathy
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by
cilu
Now, there's a real bad news: if I derive CFileDialog I still have that problem:
Code:
CMyFileDialog : public CFileDialog
{
// all the stuff
};
Code:
{
CMyFileDialog *pFD = new CMyFileDialog( TRUE );
pFD->DoModal();
delete pFD; // first-chance exception...
}
Hi cilu,
I am facing the same problem only for IA64 platform. Did you find any resolution for first-chance exception at delete statement?
Thanks,
CBP.
-
Re: CFileDialog crash in Platform SDK
Quote:
Originally Posted by
cilu
I have installed
Platform SDK Windows Server 2003 (I work in VS 6.0 on WinXP) and I have a problem with CFileDialog.
This code
Code:
void CFileTestView::OnViewFile()
{
CFileDialog dlg(TRUE);
dlg.DoModal();
}
worked just fine before defining _WIN32_WINNT, which I need to use different functions and constants. Now, when I define it
Code:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif
my code just crashes in ~CFileDialog (when dlg does out of scope and is destroyed). Since m_ofn member of CFileDialog depends on this _WIN32_WINT:
Code:
typedef struct tagOFN {
// ...
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME
I rewrote the code this way:
Code:
void CFileTestView::OnViewFile()
{
CFileDialog dlg(TRUE);
#if (_WIN32_WINNT >= 0x0500)
dlg.m_ofn.pvReserved = NULL;
dlg.m_ofn.dwReserved = 0;
dlg.m_ofn.FlagsEx = 0;
#endif
dlg.DoModal();
}
but I still get a first-chance exception in FileTest.Exe (KERNEL32.dll) 0xC0000005: Access Violation (the usual stuff).
Any ideas? Thanks!
Hi cilu,
I am facing the same problem for IA64 platform. Did you find any resolution for first-chance exception at delete statement?
Thanks,
CBP.