CFileDialog::DoModal() never returns
in [MFC]
|
From: Joseph M. Newcomer on 21 Feb 2008 23:59 There was a disaster in the VS6-XP versions because of a change in the size of the file dialog. Note that phenomena such as having too many windows, running out of GDI space, etc. can result in some of the problems you are seeing. So key here is to replicate the environment. I (and others) can do CFileDialog dlg(TRUE); dlg.DoModal(); without problem, so if it is failing for you, there is something else wrong. But since it is impossible to intuit what your entire environment must be like, it is hard to do more than guess. I'd look at resource exhaustion as a likely candidate. Can you write a trivial example that just does the CFileDialog dlg(TRUE) as above, in a little test app, and see it work? If so, then the problem is the environment your app is presenting to it. Programs like the process viewer (from www.sysinternals.com) could give some figures about things like GDI handle usage; if the numbers are far out of line, this could be the problem. joe On Thu, 21 Feb 2008 16:51:02 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote: > > >"Joseph M. Newcomer" wrote: > >> This is not a good description. If DoModal "fails", it will return 0. If it succeeds, >> you should see a dialog box. > >Sorry for my imprecise language. What shall we call it when an API >invocation does not do what the documentation purports it to do? You are >right, it did not 'fail' in the sense that it did not return a value >indicating failure. It never returned, period. However, I apparently have no >File Open dialog. At least none that I can find. > >> Presumably you are going to fill in all those parameters at some point, because you are >> using the defaults, so there is no reason to provide default parameters to the >> constructor. > >As suggested by another poster, I have also tried invoking it as CFileDialog >fileOpenBox(TRUE);, with no change in behavior. > >> I see no function f() here. > >True. Sorry again for my imprecision. f() here is meant to be shorthand for >'the function we are discussing'. More specifically, f() was meant to denote >CFileDialog::DoModal(). > >Accordingly, the symptons could be described as follows: >Something deep within the call tree of CFileDialog::DoModal() is (apparently) >failing, causing the dialog to never be displayed, and the >CFileDialog::DoModal() never to return. > >> What version of VS are you using, > >Help>About has the following to say: >Visual Studio 2005 Professional Edition >Microsoft Visual Studio 2005 >Version 8.0.50727.762 (SP.050727-7600) > >> what platform SDK, > >Quite frankly, I don't know how to check this. Is the SDK version not >inferred from the VS version? > >> what OS? > >System Information says: >Microsoft Wondows XP Professional >5.1.2600 Service Pack 2 Build 2600 > >> Not enough information here >> to even make a good guess. There are some known issues with using older > Platform SDKs on >> modern operating systems because the size of the m_ofn member changed, but they have >> typically led to unpleasant crashes, usually due to access faults or heap corruption. > >How old is old? I guess I just assumed that VS installed whatever it needed >to build working code. I have certainly used this particular MFC API call in >other projects, built on this machine, using this exact installation of VS. >Unless Windows Update changed something germane out from underneath me. > >Is there any more info that may be of use in diagnosing the problem? I was >kind of hoping someone could point to some glaring error in the parameter >list of the DoModal call, but I guess nothing there looks obviously amiss? Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 22 Feb 2008 00:51 So that means you haven't stepped deeply enough; you should have tried to Step Into. joe On Thu, 21 Feb 2008 16:32:00 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote: > > >"Mikel" wrote: > >> See below: >> > >> ************* >> Well, DoModal returns when you select a file o close the dialog, so if >> the dialog is never displayed, it's logical that it doesn't return. >> ************* > >Understood. Hence, my confusion. > >> > >> > void CPvtDlg::OnBnClickedBnFileBd() >> > { >> > >> > // specify a file >> > CFileDialog fileOpenBox ( TRUE, // BOOL bOpenFileDialog >> > NULL, // LPCTSTR lpszDefExt >> > NULL, // LPCTSTR lpszFileName >> > (OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT), >> > // DWORD dwFlags >> > NULL, // LPCTSTR lpszFilter >> > NULL ); // CWnd* pParentWnd >> >> ************ >> You are using the defaults here, so why not remove them and use just >> CFileDialog fileOpenBox(TRUE); ? >> ************ > >OK, I tried that. No apparent change. Still unable to step over the call >nResult = ::AfxCtxGetOpenFileName(&m_ofn); >witihin the implementation of INT_PTR CFileDialog::DoModal(). > > >> > I could probably continue, but it seems to me that I am inside the innards >> > of an area of the libs that I have no business in. What is it up in the API >> > level that I am screwing up? >> >> ******* >> I have tried stepping into all of the functions until it finally >> displays the dialog, so I really don't know what is going wrong. Those >> are MFC/WIN32 internals and I am not an expert on that... > >Likewise. > >> Have you checked wether the dialog is under other windows, or outside >> the screen? It shouldn't, but anyway. > >I can't seem to find it. The parent dialog *seems* to retain focus. However, >it refuses to repaint itself. Perhaps that is to be expected, anyway? Also, >all my past experience wit hthe CFileDialog is that it is displayed above all >other windows when DoModal() is invoked. At least that is my recollection. >Should it not have top-most position, and focus, in all cases? > >How do I check for it outside the screen? > >> Another thing that comes to mind, try setting breakpoints in all the >> functions in CFileDialog and see where it stops... > >Well, as reported, I can step into the MFC functions (at least to a point). >However, that should be irrelevant, right? I shouldn't have to reverse >engineer MFC in order to use MFC, should I? I never had to in the past - >although I must admit to noobishness. > >If you think it would help, I'm certainly willing to dive into the guts of >MFC, to get more specific about where things go astray. It is rather obtuse >code, however. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: jbreher on 22 Feb 2008 01:11 "Joseph M. Newcomer" wrote: > So that means you haven't stepped deeply enough; you should have tried to Step Into. As reported in the OP, I did step into the DoModal() call. Indeed, I stepped deep enough that I was soon lost in a forest of dense inscrutable macros. This may speak more to my limid mental capacity more than to anything else. However, it would seem to me that, if MFC works as advertised, I should not need to dig that deep. All ranting aside, I abandoned the hunt when I seemed to enter into a (seemingly) recursive loop, bringing me repeatedly through this indecipherable line in afxcomctl32.h: AFX_ISOLATIONAWARE_FUNC(BOOL,GetOpenFileNameW,(LPOPENFILENAMEW unnamed1),(unnamed1),FALSE) Why the code would tread through that invocation over a handful of times is beyond me. Any guesses?
From: jbreher on 22 Feb 2008 01:22 "Joseph M. Newcomer" wrote: > There was a disaster in the VS6-XP versions because of a change in the size of the file > dialog. So am I to assume that I should not have any such issues, as I am using a subsequent release of VS? > Note that phenomena such as having too many windows, running out of GDI space, etc. can > result in some of the problems you are seeing. So key here is to replicate the > environment. I (and others) can do > CFileDialog dlg(TRUE); > dlg.DoModal(); > > without problem, so if it is failing for you, there is something else wrong. But since it > is impossible to intuit what your entire environment must be like, it is hard to do more > than guess. This gives me my first insight. I had been thinking in terms of something wrong with my application directly, rather than an environmental issue. I took a detour to run another app that I built last week, which uses the same code. While it used to operate just fine, it now exhibits the same inability to DoModal(). > I'd look at resource exhaustion as a likely candidate. Can you write a trivial example > that just does the CFileDialog dlg(TRUE) as above, in a little test app, and see it work? > If so, then the problem is the environment your app is presenting to it. Programs like > the process viewer (from www.sysinternals.com) could give some figures about things like > GDI handle usage; if the numbers are far out of line, this could be the problem. I'll see if I can find said process viewer. I have used other sysinternals tools before (I recall something that monitored accesses to COM and LPT ports). I'll report back with any findings. In the meantime, if you have any links to a 'process viewer 101 training doc', it would be most appreciated.
From: jbreher on 22 Feb 2008 01:27 "Joseph M. Newcomer" wrote: > If so, then the problem is the environment your app is presenting to it. Programs like > the process viewer (from www.sysinternals.com) could give some figures about Quick follow-up question - I don't seem to be able to locate any "process viewer" from sysinternals. Might you be referring to their "Process Explorer"?
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: CMFCRibbonButton pressed state, how to do that ? Next: converting vc++2005 project to VC++2008 |