Win32 API FileOpen used in DirectShow

Hello everyone,

I've implemented a simple FileOpen dialog based on Win32 API into a DirectShow filter of mine whose property page is also created by using Win32 API. Now I have 2 problems in the FileOpen dialog:
1. Whenever I click "My Computer" then the window shows nothing. I have to choose a drive by using the combo box above. This happens in Win XP Pro, but not in Windows 7.
2. The displayed file types can be set too "All" and "Text", but whenever I switch between them, then the display is again completely white, until I move to a different folder.

I'm guessing that having 2 independent places where GUI elements are invoked doesn't work too well, because if I copy the FileOpen dialog into a small test-app then everything is fine. Am I guessing correctly?

My FileOpen code is basically the example code from MSDN. Here it is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const std::string Myclass::FileOpenDlg()
{
	OPENFILENAME ofn={0};
	char szFileName[MAX_PATH]={0};

	ZeroMemory( &ofn , sizeof( ofn));
	ofn.lStructSize = sizeof ( ofn );
	ofn.hwndOwner = NULL ;
	ofn.lpstrFile = szFileName ;
	ofn.lpstrFile[0] = '\0';
	ofn.nMaxFile = sizeof( szFileName );
	ofn.lpstrFilter = "All\0*.*\0Text\0*.TXT\0\0";
	ofn.nFilterIndex =1;
	ofn.lpstrFileTitle = NULL ;
	ofn.nMaxFileTitle = 0 ;
	ofn.lpstrInitialDir=NULL ;
	ofn.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST;
	GetOpenFileName( &ofn );

	return ofn.lpstrFile;
}


I can't switch to MFC because apart from being too much work the CFileDialog-class requires a parent window and I don't have one.

Does anyone know how to solve this or where such a problem can come from?

Regards
Squall83
Misc notes:

1) The correct way to view all files would be "*", not "*.*". "*.*" will not show files that lack an extension.

2) Your code will choke if Unicode settings are off. I recommend the below changes:

1
2
3
OPENFILENAMEA ofn={0};  // change to OPENFILENAMEA
//...
GetOpenFileNameA( &ofn );  // change to GetOpenFileNameA 
Last edited on
1) Thanks, I'll keep that in mind.

2) If adding the A forces ANSI, then - if Unicode settings are off - it should be the same whether or not I add the A, right?
Topic archived. No new replies allowed.