GetOpenFileName Hangs

[bne...@cs.utah.edu]

I'm seeing a very strange problem using the GetOpenFileName Win32
function.

Symptoms

User reported that the application hangs when they click on an open
file button. The code that is executed when the button is pressed is
as follows:

OPENFILENAME ofnFile;
TCHAR buffer[_MAX_PATH];

//_tcscpy(buffer, m_szTemplate);
memset(buffer, 0, sizeof(TCHAR)*_MAX_PATH);

memset(&ofnFile, 0, sizeof(ofnFile)); // initialize structure to
0/NULL

ofnFile.lStructSize = sizeof(ofnFile);
ofnFile.lpstrFile = buffer;
ofnFile.nMaxFile = _MAX_PATH;
ofnFile.lpstrDefExt = _T("xml");
ofnFile.lpstrFileTitle = NULL;
ofnFile.nMaxFileTitle = 0;
ofnFile.Flags |= OFN_HIDEREADONLY | OFN_ENABLESIZING | OFN_EXPLORER;
ofnFile.lpfnHook = NULL;
ofnFile.lpstrFilter = _T("XML Files\0*.xml\0\0");

BOOL dlgret = GetOpenFileName(&ofnFile);

if(dlgret){
m_szTemplate = ofnFile.lpstrFile;
UpdateData(FALSE);
}

In the debugger, we see the code up to the call to GetOpenFileName,
executing that function causes the application to hang.

One a newly installed Windows 2000 machine with SP 4 this code works as
expected. However, as soon as I installed the Visual Studio .NET 2003
prerequisites (in preparation for installing Visual Studio .NET) the
application hangs. I've verified on many machines that a Windows 2000
machine with .NET hangs but a 2000 machine without .NET works fine.
Also, we can't reproduce the hang on Windows XP.

Anyone have any ideas why this may be happening? I have seen several
recommendations out there to call CoInitializeEx and/or
InitCommonControls before the GetOpenFileName. Our application already
uses CoInitializeEx, and when I tried InitCommonControls it made no
difference.

[Grzegorz Wróbel]

bne...@cs.utah.edu wrote:

> I'm seeing a very strange problem using the GetOpenFileName Win32
> function.
>
> Symptoms
>
> User reported that the application hangs when they click on an open
> file button. The code that is executed when the button is pressed is
> as follows:

You forgot to set hinstance and hwndOwner fields of OPENFILENAME struct.

> ofnFile.lpstrFileTitle = NULL;
> ofnFile.nMaxFileTitle = 0;

These lines are redundant since you've memset entire struct to 0.

--
677265676F727940346E6575726F6E732E636F6D

[bne...@cs.utah.edu]

You are right about the redundant entries.

As far as hinstance and hwndOwner fields, from the documentation it
doesn't appear that these are needed. I can specify a NULL owner
(which can cause problems if the user goes back to the main window, but
that really isn't an issue here), and the other field isn't used
because I'm not setting the flags that require it.

I recently tried CFileDialog (this is an MFC app) and the same thing
happens.

[TC]

Just a guess (cos I don't do much C) - are you sure that the following
line passes the /address/ of the buffer?

> ofnFile.lpstrFile = buffer;

HTH,
TC

[bne...@cs.utah.edu]

Yes, ofnFile.lpstrFile = buffer does assign the pointer.

When I do the following:

CFileDialog d(TRUE);
d.DoModal();

I get the same result. The application hangs if visual studio .NET
2003 is installed and works correctly otherwise.

[bne...@cs.utah.edu]

Now here's something interesting. Earlier in my program I have the
following:

HRESULT hRes = CoInitializeEx(NULL, COINIT_MULTITHREADED);

If I comment this out the open file dialog works correctly. Anyone

have any ideas why this may be happening?

Thanks.

[Grzegorz Wróbel]

bne...@cs.utah.edu wrote:
> You are right about the redundant entries.
>
> As far as hinstance and hwndOwner fields, from the documentation it
> doesn't appear that these are needed.

You're right, they're not necessary.
I don't see anything in the code provided that could cause behaviour you described.
Maybe it's some Unicode support flaw? Did you try to compile this as ANSI(if possible) and see if this happens as well?

--
677265676F727940346E6575726F6E732E636F6D

[David Lowndes]

Many of the shell APIs don't like multi-threaded COM. See the remarks
section of the documentation on SHBrowseForFolder for an example.

Dave

[Carsten Neubauer]

bne...@cs.utah.edu wrote:
> ...

> HRESULT hRes = CoInitializeEx(NULL, COINIT_MULTITHREADED);
>
> If I comment this out the open file dialog works correctly.
> Anyone have any ideas why this may be happening?

perhaps the following threads contain some info,
otherwise, google is your friend.

1) FileOpen Dialog Hangs after a CoInitializeEx under Windows 2000
http://groups.google.de/group/microsoft.public.win32.programmer.ole/browse_frm/thread/e3fa6ac803adb7cd/8b423dfb00476b84?lnk=st&q=CoInitializeEx&rnum=2&hl=de#8b423dfb00476b84

2) CoInitializeEx COINIT_MULTITHREADED and ShellExecute (and ...
http://groups.google.de/group/microsoft.public.vc.mfc/browse_frm/thread/d126a29cfd1fb718/1ac9d84b5b486483?lnk=st&q=CoInitializeEx&rnum=3&hl=de#1ac9d84b5b486483

hope it helps,
carsten neubauer
speech recognition, compression, custom development
http://www.c14sw.de/100.html

[bne...@cs.utah.edu]

I had googled it for weeks, but since I had never connected the
CoInitializeEx function and GetOpenFileName I never found these
answers.

Making COM single threaded solved all of the problems. Thanks
everyone.

Blake