|
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 | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
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 | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
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++
|
|
|
|
|
>>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'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++
|
|
|
|
|
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 CFileDialog may 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
|
|
|
|
|
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[^]
|
|
|
|
|
Wow, great link, I've had this problem for a good while on one particular machine, kind of forgot about until now.
|
|
|
|
|
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
|
|
|
|
|
Hi,
If I have to examine a .dmp file using windbg.exe and I use the following SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols to download
the OS symbols then am I doing it right. Will windbg ensure to download the correct symbols based on the .dmp file that was generated. ie. will windbg ensure to download the correct symbols based on the xp version (service pack etc) on which the .dmp file was generated.
Thanks
Rajdeep
|
|
|
|
|
Hi all
I want the program to compare two using C++.gif files.If there is any win32 API then let me know.
Thanks
Subrat
|
|
|
|
|
Hi all
I want the program to compare two .gif files using C++.If there is any win32 API then let me know.
Thanks
Subrat
|
|
|
|
|
Hi Member 4708266,
Are you by chance looking for a program to compare two .gif files using C++?
[added]
BTW
There is the following function
BOOL PleaseCompareTheseGifFiles(LPCTSTR szGifAFilename, LPCTSTR szGifBFilename);
exported by the CompareStuff library available for free on www.freproductz.cpallini.com[^].
[/added]
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified on Wednesday, October 15, 2008 11:30 AM
|
|
|
|
|
You did not mention the magic site
Regards,
Sandip.
|
|
|
|
|
Fixed.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You're so mean...
Isn't the name of the function PlzComparezDaFilez(..) ?
|
|
|
|
|
Michael Schubert wrote: PlzComparezDaFilez
With the above name it is exported by the DLL only if you compile it defining the SMS_SLANGZ symbol.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
CPallini wrote: available for free on www.freproductz.cpallini.com[^].
And if you call in the next 10 minutes, we'll SUPERSIZE your order!
That's right! You'll get TWO CompareStuff libraries FOR THE PRICE OF ONE!
CALL NOW!!!!!
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
