CRUCIAL HELP: CFileDialog and GetOpenFileName cause assertion

Michael Hupp

unread,

Mar 14, 1997, 3:00:00 AM3/14/97

to

Hello all,

Thank you in advance for any help on this subject.

We are desperately hoping someone will have the answer to this. I have
searched MSDN, the Knowledge Base, FAQ to no avail.

Our problem:

We have recently ported all of our 16 bit MFC applications to 32 bit using
Visual C++ 4.2 professional. All applications use MFC as a shared DLL and
are set to use the Muti-threaded DLL run-time library (in the C/C++/Code
Generation tab of the project settings). These applications are running
under Windows NT 4.0 (some have SP2 some do not, but it happens on all
systems).

Whenever we call CWinApp::OnFileOpen() our applications ASSERT at:
File: winocc.cpp
Line: 193

The File Open Dialog (MFC's CFileDialog) is displayed and then the
assertion dialog is displayed over the top of the File Open Dialog.

The closest thing I could find in the KB is the following article:
PSS ID Number: Q140726
Article last modified on 12-11-1995

4.00

WINDOWS

---------------------------------------------------------------------
The information in this article applies to:

- Microsoft Win32 Application Programming Interface (API) included
with Microsoft Windows 95
---------------------------------------------------------------------

SUMMARY
=======

You can have a 16-bit application running under Windows 95 take advantage
of the new Explorer-style FileOpen common dialog by thunking up to a 32-bit
DLL, specifying the OFN_EXPLORER style from that DLL, and linking it with
the new COMDLG32.DLL. This, however, causes the old-style dialog to come
up, instead of the new Explorer-style dialog.

MORE INFORMATION
================

Although the common dialog function is called from the 32-bit DLL,
COMDLG32.DLL detects that the current process is still a 16-bit application
and quickly reverts back to the old-style File Open common dialog. This is
because the new Explorer-style dialog uses multiple threads, which 16-bit
applications do not support.

The only way for a 16-bit application to take advantage of the new
Explorer-
style functionality is to port to Win32 and make the call to
GetOpenFileName() directly.

Additional reference words: 4.00 kbinf
KBCategory: kbprg
KBSubcategory: UsrCmnDlg
============================================================================
=
Copyright Microsoft Corporation 1995.

The same exact thing happens if we call GetOpenFileName directly.

It only occurs in the 16 bit apps ported to 32 bit. Any native 32 bit app
generated via Visual C++ 4.2 work fine.

We are completely lost and are trying to release our product. Any help you
could supply would be greatly appreciated.

Thank you, thank you, thank you,
Michael

Aaron J Margosis

unread,

Mar 14, 1997, 3:00:00 AM3/14/97

to

My guess is that you're supplying incorrect information in the
OPENFILENAME structure.

Post your code and let's have a look at it.

-- Aaron

---------------------------------
Aaron J Margosis
Work e-mail: marg...@lccinc.com
Work phone: 703-873-2622 (703-USE-A-MAC ??!!)
Personal: Aaron_M...@compuserve.com

Ed Dore

unread,

Mar 14, 1997, 3:00:00 AM3/14/97

to

Hi Michael,

Line 193 in WINOCC.CPP is the ASSERT statement in the following function:

DWORD CWnd::GetStyle() const
{
ASSERT(::IsWindow(m_hWnd));

if (m_pCtrlSite == NULL)
return (DWORD)GetWindowLong(m_hWnd, GWL_STYLE);
else
return m_pCtrlSite->GetStyle();
}

I think there's something else going on here. Can you post a callstack
after you hit the assert? This might give us a better idea of where/why the
problem is occuring. Also, where are you calling this function from?

Thanks,
Ed....

Michael Hupp

unread,

Mar 14, 1997, 3:00:00 AM3/14/97

to

Thanks to all who read this and may have attempted to help.

It turned out that one of our MFC DLLs we were loading was not using the
AFX_MANAGE_STATE macro so the App/Windows was getting confused.

Everythings works fine now.

Michael