MFC App (Visual Studio 6) hangs when you click File, Open.
-
I have an MFC, multi-document template application, built using Visual Studio 6, which has been working for a long time now. Recently I moved to a new development machine and now my application hangs whenever I click the File menu and choose Open. I have run it in debug mode and traced into the MFC code. The point of failure is in DlgFile.cpp(part of Microsoft's MFC source) at line 108 where it calls ::GetOpenFileName(&m_ofn). It goes in there never to return. I spotted that the m_ofn structure points at a hook function _AfxCommDlgProc so I set a break point in that. The dialog receives the following windows messages before the application hangs: WM_SETFONT, WM_INITDLG, WM_SHOWWINDOW, WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_CHILDACTIVATE, WM_WINDOWPOSCHANGED then WM_SIZE. The WM_SIZE message is processed OK and AfxCommDlgProc then exits back to code for which source is unavailable. My dialog never receives another message. As a control I then tried exactly the same experiment on another MFC application of mine - one which doesn't fail. It acts exactly the same except that the WM_SIZE message is followed (after a short but noticable delay) by a WM_SETREDRAW after which the Open File dialog box appears. If I let the failing application hang then click on Debug, Break, the call stack is singularly uninformative: NTDLL! 7c90eb94() USER32! 7e4195f9() USER32! 7e4196a8() BROWSEUI! 75f8afc9() BROWSEUI! 75f8b591() SHLWAPI! 77f69588() NTDLL! 7c927545() NTDLL! 7c927583() NTDLL! 7c927645() NTDLL! 7c92761c() KERNEL32! 7c80b683() I am at my wits end. I am using the standard MFC file open mechanism with no undue cleverness. I can see no tangible difference between the failing application and a different application which works, apart from the file types it's looking for. Has anyone any sensible suggestions what to try next? Keith
-
I have an MFC, multi-document template application, built using Visual Studio 6, which has been working for a long time now. Recently I moved to a new development machine and now my application hangs whenever I click the File menu and choose Open. I have run it in debug mode and traced into the MFC code. The point of failure is in DlgFile.cpp(part of Microsoft's MFC source) at line 108 where it calls ::GetOpenFileName(&m_ofn). It goes in there never to return. I spotted that the m_ofn structure points at a hook function _AfxCommDlgProc so I set a break point in that. The dialog receives the following windows messages before the application hangs: WM_SETFONT, WM_INITDLG, WM_SHOWWINDOW, WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_CHILDACTIVATE, WM_WINDOWPOSCHANGED then WM_SIZE. The WM_SIZE message is processed OK and AfxCommDlgProc then exits back to code for which source is unavailable. My dialog never receives another message. As a control I then tried exactly the same experiment on another MFC application of mine - one which doesn't fail. It acts exactly the same except that the WM_SIZE message is followed (after a short but noticable delay) by a WM_SETREDRAW after which the Open File dialog box appears. If I let the failing application hang then click on Debug, Break, the call stack is singularly uninformative: NTDLL! 7c90eb94() USER32! 7e4195f9() USER32! 7e4196a8() BROWSEUI! 75f8afc9() BROWSEUI! 75f8b591() SHLWAPI! 77f69588() NTDLL! 7c927545() NTDLL! 7c927583() NTDLL! 7c927645() NTDLL! 7c92761c() KERNEL32! 7c80b683() I am at my wits end. I am using the standard MFC file open mechanism with no undue cleverness. I can see no tangible difference between the failing application and a different application which works, apart from the file types it's looking for. Has anyone any sensible suggestions what to try next? Keith
Does it timeout and eventually show or hang forever? Is it waiting for a reply from a network drive?
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
I have an MFC, multi-document template application, built using Visual Studio 6, which has been working for a long time now. Recently I moved to a new development machine and now my application hangs whenever I click the File menu and choose Open. I have run it in debug mode and traced into the MFC code. The point of failure is in DlgFile.cpp(part of Microsoft's MFC source) at line 108 where it calls ::GetOpenFileName(&m_ofn). It goes in there never to return. I spotted that the m_ofn structure points at a hook function _AfxCommDlgProc so I set a break point in that. The dialog receives the following windows messages before the application hangs: WM_SETFONT, WM_INITDLG, WM_SHOWWINDOW, WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_CHILDACTIVATE, WM_WINDOWPOSCHANGED then WM_SIZE. The WM_SIZE message is processed OK and AfxCommDlgProc then exits back to code for which source is unavailable. My dialog never receives another message. As a control I then tried exactly the same experiment on another MFC application of mine - one which doesn't fail. It acts exactly the same except that the WM_SIZE message is followed (after a short but noticable delay) by a WM_SETREDRAW after which the Open File dialog box appears. If I let the failing application hang then click on Debug, Break, the call stack is singularly uninformative: NTDLL! 7c90eb94() USER32! 7e4195f9() USER32! 7e4196a8() BROWSEUI! 75f8afc9() BROWSEUI! 75f8b591() SHLWAPI! 77f69588() NTDLL! 7c927545() NTDLL! 7c927583() NTDLL! 7c927645() NTDLL! 7c92761c() KERNEL32! 7c80b683() I am at my wits end. I am using the standard MFC file open mechanism with no undue cleverness. I can see no tangible difference between the failing application and a different application which works, apart from the file types it's looking for. Has anyone any sensible suggestions what to try next? Keith
I had a similar problem in which the standard MFC application was crashing on certain action inside file open dialog on few machines with a simple code..... The problem for me was solved for me after downloading a windows hotfix refer to this link if you can find something http://www.bokebb.com/dev/english/1960/posts/196055272.shtml[^]
-
Does it timeout and eventually show or hang forever? Is it waiting for a reply from a network drive?
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
Does it timeout and eventually show or hang forever? Is it waiting for a reply from a network drive?
So far as I know it hangs forever - but forever is a long time :) I may just not have stuck around long enough. I don't think it's a network drive issue because I have two similar applications. One always hangs and the other always works. There is clearly a tangible difference between the two but I can't figure out what it is. Keith
-
I had a similar problem in which the standard MFC application was crashing on certain action inside file open dialog on few machines with a simple code..... The problem for me was solved for me after downloading a windows hotfix refer to this link if you can find something http://www.bokebb.com/dev/english/1960/posts/196055272.shtml[^]
-
I had a similar problem in which the standard MFC application was crashing on certain action inside file open dialog on few machines with a simple code..... The problem for me was solved for me after downloading a windows hotfix refer to this link if you can find something http://www.bokebb.com/dev/english/1960/posts/196055272.shtml[^]
Thanks for the suggestion. I did follow up the link you posted but I think that situation is different. It was a crash, rather than a hang, and it occurred after the open-file dialog box was displayed. In my case the dialog is never displayed. It hangs before it gets to that point. Keith
-
Mark Salsbery wrote:
Does it timeout and eventually show or hang forever? Is it waiting for a reply from a network drive?
So far as I know it hangs forever - but forever is a long time :) I may just not have stuck around long enough. I don't think it's a network drive issue because I have two similar applications. One always hangs and the other always works. There is clearly a tangible difference between the two but I can't figure out what it is. Keith
Does this code ripped right from the docs fail as well?
TCHAR szFilters[]= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
if(fileDlg.DoModal() == IDOK)
{
}Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Thanks for the suggestion. I did follow up the link you posted but I think that situation is different. It was a crash, rather than a hang, and it occurred after the open-file dialog box was displayed. In my case the dialog is never displayed. It hangs before it gets to that point. Keith
I just meant some other hotfix might be able to solve the problem...any way good luck this is all I know
-
Does this code ripped right from the docs fail as well?
TCHAR szFilters[]= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
if(fileDlg.DoModal() == IDOK)
{
}Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark I was wrong. It doesn't hang forever. I decided to leave it whilst running a stop watch. After clicking File, Open there is (on my laptop) a 1 minute and 50 seconds delay before the standard open dialog appears. This is solidly repeatable. If I cancel the open-file dialog and then click File Open again then there is another 1:50 delay until the open-file dialog reappears. I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay. Keith
-
Mark I was wrong. It doesn't hang forever. I decided to leave it whilst running a stop watch. After clicking File, Open there is (on my laptop) a 1 minute and 50 seconds delay before the standard open dialog appears. This is solidly repeatable. If I cancel the open-file dialog and then click File Open again then there is another 1:50 delay until the open-file dialog reappears. I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay. Keith
Keith (MapMan) wrote:
The identical code, pasted into another application, works without any delay.
That's not good :) I'm thinking...
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Keith (MapMan) wrote:
The identical code, pasted into another application, works without any delay.
That's not good :) I'm thinking...
Mark Salsbery Microsoft MVP - Visual C++ :java:
>>I'm thinking... I'm giving up for today so no rush. One more bit of information. File Save As exhibits same long delay before displaying dialog. Keith
-
Mark I was wrong. It doesn't hang forever. I decided to leave it whilst running a stop watch. After clicking File, Open there is (on my laptop) a 1 minute and 50 seconds delay before the standard open dialog appears. This is solidly repeatable. If I cancel the open-file dialog and then click File Open again then there is another 1:50 delay until the open-file dialog reappears. I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay. Keith
Keith (MapMan) wrote:
I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay.
That makes it sounds as though
CFileDialogmay not be the problem. How about just creating a dummy MDI application to see what it does with all of the default settings and code?"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
Keith (MapMan) wrote:
I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay.
That makes it sounds as though
CFileDialogmay not be the problem. How about just creating a dummy MDI application to see what it does with all of the default settings and code?"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
I think you're probably right that it's not CFileDialog's problem as such. Something else about the application is causing the problem. I'm pretty confident that if I created another dummy MDI app it would not exhibit the problem because I already have other real, not dummy, MDI apps which don't exhibit this behaviour. What I think I might do is take a copy of the failing application and start knocking bits out of it to see if I can find something which makes it work. If I don't get anywhere that way then I may try as you suggest, start with a brand new project then gradually add back in the functionality of my app. It's going to be a long haul, though. There's rather a lot of it. Keith
-
Keith (MapMan) wrote:
The identical code, pasted into another application, works without any delay.
That's not good :) I'm thinking...
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark >>I'm thinking... If you are still thinking, stop. What my computer needed (apparently) was a good night's sleep. This morning I cannot reproduce the problem. The application works perfectly! Contrary or what? I've not even rebooted in the interim. At the end of the day I just shut the lid on my laptop and it hibernates. I fired it up briefly at home yesterday evening to check my emails (didn't even try to run the failing app) then this morning I started again, connected to the same office network environment as yesterday, and the problem has magically gone away. I guess we shall just have to put it down to one of those strange abberations that computers seem to have from time to time. If anyone has any theories I'd be interested to hear them but I suspect they will have to remain just that, theories. Keith
-
Mark >>I'm thinking... If you are still thinking, stop. What my computer needed (apparently) was a good night's sleep. This morning I cannot reproduce the problem. The application works perfectly! Contrary or what? I've not even rebooted in the interim. At the end of the day I just shut the lid on my laptop and it hibernates. I fired it up briefly at home yesterday evening to check my emails (didn't even try to run the failing app) then this morning I started again, connected to the same office network environment as yesterday, and the problem has magically gone away. I guess we shall just have to put it down to one of those strange abberations that computers seem to have from time to time. If anyone has any theories I'd be interested to hear them but I suspect they will have to remain just that, theories. Keith
Crazy :) Thanks for the update! Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: