背景:vs2005,win32 api 编写的打开文件对话框是我工程的一部分。以前用一直好着呢,最近给我工程加了一点功能,此功能与打开对话框没有一毛钱的关系。所以也没有想到会打开失败。今天试了一下,突然打开文件时,异常,超级郁闷。同样的代码在别人那里还可以用。
我的打开文件对话框函数如下:BOOL OpenFileDlg(HWND hwnd, OPENFILENAME* p_ofn)
{
if(hwnd == NULL)
return false; TCHAR szFile[MAX_PATH + 1]; // buffer for file name // Initialize OPENFILENAME
::ZeroMemory(p_ofn, sizeof(*p_ofn));
p_ofn->lStructSize = sizeof(*p_ofn);
p_ofn->hwndOwner = hwnd;
p_ofn->lpstrFile = szFile;
// Set lpstrFile[0] to '\0' so that GetOpenFileName does not
// use the contents of szFile to initialize itself.
p_ofn->lpstrFile[0] = '\0';
p_ofn->nMaxFile = MAX_PATH;
p_ofn->lpstrFilter = NULL;
p_ofn->nFilterIndex = 1;
p_ofn->lpstrFileTitle = NULL;
p_ofn->nMaxFileTitle = 0;
p_ofn->lpstrInitialDir = NULL;//
p_ofn->Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
// Display the Open dialog box.
return ::GetOpenFileName(p_ofn);
}在窗口过程中调用:case IDM_OPEN:
{
OPENFILENAME ofn;
if(::OpenFileDlg(hWnd,&ofn) == TRUE)
::MessageBox(NULL,ofn.lpstrFile,TEXT("file name"),MB_OK);
}跟踪发现GetOpenFileName()函数内部抛出的异常,异常内容为:
First-chance exception at 0x774bf992 in OmniPlayer.exe: 0xC0000008: An invalid handle was specified.
但是在忽略该异常后,
GetOpenFileName()函数竟然返回的还是TRUE.可是拿到的文件路径变成了乱码。于是乎,我就在MFC里做了一个测试:
首先,建立一个基于对话框的mfc工程, 加一个button, on-button里如下:void CTESTSFSSFSFDlg::OnBnClickedButton1()
{
// TODO: Add your control notification handle
CFileDialog dlg(TRUE, NULL, NULL ,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
NULL, NULL);
if(dlg.DoModal()==IDOK)
{
::MessageBox(this->m_hWnd,dlg.m_ofn.lpstrFile ,TEXT("str file dir"),MB_OK);
return;
}
}
同样的异常在DoModal()内部跳出,跟进去发现,错误依然在GetOpenFileName()函数处。当我强制继续时,获取到的文件路径是对的。后来发现,我以前编的其他工程,重新编译后,出现了同样悲剧的命运。同志们,救救我吧。
我的打开文件对话框函数如下:BOOL OpenFileDlg(HWND hwnd, OPENFILENAME* p_ofn)
{
if(hwnd == NULL)
return false; TCHAR szFile[MAX_PATH + 1]; // buffer for file name // Initialize OPENFILENAME
::ZeroMemory(p_ofn, sizeof(*p_ofn));
p_ofn->lStructSize = sizeof(*p_ofn);
p_ofn->hwndOwner = hwnd;
p_ofn->lpstrFile = szFile;
// Set lpstrFile[0] to '\0' so that GetOpenFileName does not
// use the contents of szFile to initialize itself.
p_ofn->lpstrFile[0] = '\0';
p_ofn->nMaxFile = MAX_PATH;
p_ofn->lpstrFilter = NULL;
p_ofn->nFilterIndex = 1;
p_ofn->lpstrFileTitle = NULL;
p_ofn->nMaxFileTitle = 0;
p_ofn->lpstrInitialDir = NULL;//
p_ofn->Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
// Display the Open dialog box.
return ::GetOpenFileName(p_ofn);
}在窗口过程中调用:case IDM_OPEN:
{
OPENFILENAME ofn;
if(::OpenFileDlg(hWnd,&ofn) == TRUE)
::MessageBox(NULL,ofn.lpstrFile,TEXT("file name"),MB_OK);
}跟踪发现GetOpenFileName()函数内部抛出的异常,异常内容为:
First-chance exception at 0x774bf992 in OmniPlayer.exe: 0xC0000008: An invalid handle was specified.
但是在忽略该异常后,
GetOpenFileName()函数竟然返回的还是TRUE.可是拿到的文件路径变成了乱码。于是乎,我就在MFC里做了一个测试:
首先,建立一个基于对话框的mfc工程, 加一个button, on-button里如下:void CTESTSFSSFSFDlg::OnBnClickedButton1()
{
// TODO: Add your control notification handle
CFileDialog dlg(TRUE, NULL, NULL ,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
NULL, NULL);
if(dlg.DoModal()==IDOK)
{
::MessageBox(this->m_hWnd,dlg.m_ofn.lpstrFile ,TEXT("str file dir"),MB_OK);
return;
}
}
同样的异常在DoModal()内部跳出,跟进去发现,错误依然在GetOpenFileName()函数处。当我强制继续时,获取到的文件路径是对的。后来发现,我以前编的其他工程,重新编译后,出现了同样悲剧的命运。同志们,救救我吧。
> ntdll.dll!774bf992()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!774bf992()
KernelBase.dll!74d9b75d()
kernel32.dll!768b13f8()
TortoiseSVN.dll!04012aab()
TortoiseSVN.dll!04013214()
TortoiseSVN.dll!04013239()
ntdll.dll!775705d6()
ntdll.dll!7752ac4b()
ntdll.dll!774d3b23()
ntdll.dll!775705d6()
ntdll.dll!7752ac4b()
ntdll.dll!774d3b23()
ntdll.dll!774d3b23()
ntdll.dll!774d3b4e()
ntdll.dll!774d3b23()
ntdll.dll!774d3b4e()
ntdll.dll!774d3b23()
ntdll.dll!774d3b4e()
msvcr90.dll!734069ed()
TortoiseSVN.dll!03fab2bd()
TortoiseSVN.dll!03fb7958()
TortoiseSVN.dll!03fbaa45()
TortoiseSVN.dll!04011976()
kernel32.dll!768b2230()
TortoiseSVN.dll!03fa10f8()
TortoiseSVN.dll!040116c1()
ntdll.dll!774bf992()
kernel32.dll!768b2642()
kernel32.dll!768b25d0()
TortoiseSVN.dll!04011a3b()
TortoiseSVN.dll!04011b89()
kernel32.dll!768b25d0()
TortoiseSVN.dll!03fa5846()
TortoiseSVN.dll!040053e6()
ntdll.dll!774d609f()
ntdll.dll!774d60a4()
ntdll.dll!774bfa5a()
ntdll.dll!774d60a4()
kernel32.dll!768b216c()
kernel32.dll!768b2179()
ntdll.dll!7752a3c8()
ntdll.dll!774d36fa()
ntdll.dll!7752aa26()
ntdll.dll!774d36fa()
shlwapi.dll!7657ed47()
ntdll.dll!774bfa8a()
KernelBase.dll!74da594b()
KernelBase.dll!74da5bf0()
ntdll.dll!7756fd6e()
ntdll.dll!77570d18()
ntdll.dll!77570cfc()
ntdll.dll!77570cfc()
ntdll.dll!7752a967()
ntdll.dll!774d609f()
ntdll.dll!774d60a4()
ntdll.dll!774d60a4()
kernel32.dll!768b2736()
kernel32.dll!768b2762()
shell32.dll!74f0c7a8()
ntdll.dll!774d7c78()
kernel32.dll!768b2a18()
kernel32.dll!768b28de()
kernel32.dll!768b28e5()
kernel32.dll!768b28e5()
kernel32.dll!768b27b5()
shell32.dll!74ebf6a6()
shell32.dll!74ebf6bb()
ntdll.dll!774d609f()
ntdll.dll!774d60a4()
ntdll.dll!774bfa5a()
ntdll.dll!774d60a4()
kernel32.dll!768b216c()
kernel32.dll!768b2179()
ntdll.dll!774d609f()
ntdll.dll!774d60a4()
ntdll.dll!774d60a4()
kernel32.dll!768b2736()
kernel32.dll!768b2762()
kernel32.dll!768b2230()
kernel32.dll!768b2289()
kernel32.dll!768b2291()
ntdll.dll!774d3b23()
kernel32.dll!768b2762()
shlwapi.dll!7657ed47()
shlwapi.dll!7657ed58()
shlwapi.dll!7657ed79()
shlwapi.dll!7657e907()
shlwapi.dll!7657e916()
shlwapi.dll!7657e925()
ntdll.dll!774bf992()
kernel32.dll!768b2642()
kernel32.dll!768b25d0()
kernel32.dll!768b25d0()
shell32.dll!74ebf700()
shell32.dll!74ec2660()
shell32.dll!74ec266d()
shell32.dll!74ebf43f()
shell32.dll!74ebf467()
shell32.dll!74f191ed()
shell32.dll!74f19212()
shell32.dll!74f19260()
shell32.dll!74f05b43()
shell32.dll!74f05b4f()
shell32.dll!74f05747()
shell32.dll!74f05786()
shell32.dll!74f0579f() 不知道有没有帮助
原来是svn在作怪。
解决方案:
当我编译任何一个由vs2005构建的工程时,总是要加载svn的dll。所以就怀疑到了svn上,卸载svn后,一切正常。
至于具体原因,实在搞不懂,不管怎样,解决了。svn,这个东西不简单,以后还得小心点~~~