Prev: CMFCRibbonButton pressed state, how to do that ?
Next: converting vc++2005 project to VC++2008
From: Norbert Unterberg on 22 Feb 2008 08:44
jbreher schrieb:
>
> "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.

Opening the file open dialog causes possibly all explorer shell
extensions and plug-ins to be loaded into your application's context.
The file open dialog contains a full featured explorer window.

So it can actually happen that some shell extension does not work
correctly within your application.

You should try to remove some of the shell extension. Does anybody know
a tool to display (and disable) all extensions that are registered and
hooked into explorer?

Norbert


>
>> 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?
From: Alexander Grigoriev on 22 Feb 2008 10:07
Make sure you don't call CoInitializeEx(COINIT_MULTITHREADED) before that.

When you get the call to hang, break inside the debugger and check the call
stack.

"jbreher" <jbreher(a)discussions.microsoft.com> wrote in message
news:4B01B52F-ED20-4E7D-9928-7BC6E8785B80(a)microsoft.com...
>I am encountering a wierd error, and I can't figure out which way to turn.
> Something deep within the call tree of CFileDialog::DoModal() is
> (apparently)
> failing, causing the dialog to never be displayed, and the f() never to
> return. Here's the failing code:
>
> 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
>
> // extract file name
> if( IDOK == fileOpenBox.DoModal() )
> {
> m_strFileNameBd = fileOpenBox.GetFileName();
> m_strPathNameBd = fileOpenBox.GetPathName();
> }
> ...
>
> Single stepping, I am unable to step over the DoModal() call. Stepping
> into
> the call to DoModal(), I find myself inside dlgfile.cpp:
>
> INT_PTR CFileDialog::DoModal()
> {
> ASSERT_VALID(this);
> ASSERT(m_ofn.Flags & OFN_ENABLEHOOK);
> ASSERT(m_ofn.lpfnHook != NULL); // can still be a user hook
>
> // zero out the file buffer for consistent parsing later
> ASSERT(AfxIsValidAddress(m_ofn.lpstrFile, m_ofn.nMaxFile));
> DWORD nOffset = lstrlen(m_ofn.lpstrFile)+1;
> ASSERT(nOffset <= m_ofn.nMaxFile);
> memset(m_ofn.lpstrFile+nOffset, 0,
> (m_ofn.nMaxFile-nOffset)*sizeof(TCHAR));
>
> // This is a special case for the file open/save dialog,
> // which sometimes pumps while it is coming up but before it has
> // disabled the main window.
> HWND hWndFocus = ::GetFocus();
> BOOL bEnableParent = FALSE;
> m_ofn.hwndOwner = PreModal();
> AfxUnhookWindowCreate();
> if (m_ofn.hwndOwner != NULL && ::IsWindowEnabled(m_ofn.hwndOwner))
> {
> bEnableParent = TRUE;
> ::EnableWindow(m_ofn.hwndOwner, FALSE);
> }
>
> _AFX_THREAD_STATE* pThreadState = AfxGetThreadState();
> ASSERT(pThreadState->m_pAlternateWndInit == NULL);
>
> if (m_ofn.Flags & OFN_EXPLORER)
> pThreadState->m_pAlternateWndInit = this;
> else
> AfxHookWindowCreate(this);
>
> INT_PTR nResult;
> if (m_bOpenFileDialog)
> nResult = ::AfxCtxGetOpenFileName(&m_ofn);
> else
> nResult = ::AfxCtxGetSaveFileName(&m_ofn);
> ...
> I am unable to step over the call to ::AfxCtxGetOpenFileName(&m_ofn); in
> the
> if branch above. Stepping into it allows me to step through
>
> OPENFILENAME& CFileDialog::GetOFN()
> {
> return *m_pOFN;
> }
>
> and
>
> COMMDLG_AFXCTXFUNC(BOOL,GetOpenFileNameW,(LPOPENFILENAMEW
> unnamed1),(unnamed1))
>
> to
>
> AFX_MODULE_STATE* AFXAPI AfxGetModuleState()
> {
> _AFX_THREAD_STATE* pState = _afxThreadState;
> ENSURE(pState);
> AFX_MODULE_STATE* pResult;
> if (pState->m_pModuleState != NULL)
> {
> // thread state's module state serves as override
> pResult = pState->m_pModuleState;
> }
> else
> {
> // otherwise, use global app state
> pResult = _afxBaseModuleState.GetData();
> }
> ENSURE(pResult != NULL);
> return pResult;
> }
>
> back through
>
> COMMDLG_AFXCTXFUNC(BOOL,GetOpenFileNameW,(LPOPENFILENAMEW
> unnamed1),(unnamed1))
>
> 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?


From: jbreher on 22 Feb 2008 11:55


"Norbert Unterberg" wrote:

>
> Opening the file open dialog causes possibly all explorer shell
> extensions and plug-ins to be loaded into your application's context.
> The file open dialog contains a full featured explorer window.
>
> So it can actually happen that some shell extension does not work
> correctly within your application.
>
> You should try to remove some of the shell extension. Does anybody know
> a tool to display (and disable) all extensions that are registered and
> hooked into explorer?
>
> Norbert
>

I am afraid that I do not have the necessary background to understand how to
make use of this information. By 'shell extension', are you speaking of
third-party things that integrate themselves into the Explorer interface?
(e.g. WinZip, Tortoise-SVN, etc.)

I am certainly more than happy to disable such extensions - as a debugging
mechanism if nothing else. However, I do not know how to determine what
extensions I may have running, nor how to actually disable them once
identified.
From: jbreher on 22 Feb 2008 12:06


"Alexander Grigoriev" wrote:

> Make sure you don't call CoInitializeEx(COINIT_MULTITHREADED) before that.

I certainly do not call it explicitly. However, if operations upon some
other MFC object may have invoked this 'under the hood', I wouldn't know.

> When you get the call to hang, break inside the debugger and check the call
> stack.

I tried that before my orignal post (guess I should have indicated such -
sorry). Upon Hitting the Break All button, I get the following dialog:

Microsoft Visual Studio [?][X]
<!> No symbols can be loaded for any call stack frame. The source code
cannot be displayed.
[_] Show disassembly automatically
[ OK ] [Show Disassembly]

I have tried to decipher what the assembly code is trying to do. However,
the lack of symbols makes this rather inscrutable as well.


From: Drew on 22 Feb 2008 13:21

"jbreher" <jbreher(a)discussions.microsoft.com> wrote in message
news:50CA8FB8-6EF5-4972-88E6-A7C6D594AF69(a)microsoft.com...
>
>
> "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().

If you think you may have (or some other program may have) exhausted your
resources just reboot and try your app again.

Drew


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