The worlds most elusive bug : Something to do with CFileDialog

Darn! Must be fooling around too much lately. Here it is, Brandon!
Thanks a lot! :)

Darn! That's strange! I downloaded the file and it's ok!
Anyway, here's the code :

//function for searching files of a given extension(strFileExt) and listing them in extended combo box
//nImage is the index of the graphic in the imagelist
void ListSoundFiles(CComboBoxEx& comboBox, CString strFolderName, CString strFileExt, int nImage)
{
//get sound files from Sounds folder and list 'em in sounds
//combo box
CFileFind fileFind;
CStringArray arFileTitles;
CString strCurrentFileExt = "";
strFileExt.MakeUpper();

COMBOBOXEXITEM cbItem;
ZeroMemory(&cbItem,sizeof(COMBOBOXEXITEM));
cbItem.mask = CBEIF_IMAGE | CBEIF_TEXT | CBEIF_SELECTEDIMAGE;

BOOL bFound = fileFind.FindFile(strFolderName + "\\*.*");
AfxMessageBox(bFound? "T" : "F");
while(bFound)
{
bFound = fileFind.FindNextFile();

strCurrentFileExt = fileFind.GetFileName().Right(3);
strCurrentFileExt.MakeUpper();
if(strCurrentFileExt == strFileExt)
{
arFileTitles.Add(fileFind.GetFileTitle());
}
}
fileFind.Close();

std::sort(arFileTitles.GetData(),arFileTitles.GetData() + arFileTitles.GetSize());

for(int i = 0; i < arFileTitles.GetSize(); i++)
{
cbItem.iItem = i;
cbItem.iImage = cbItem.iSelectedImage = nImage;
cbItem.pszText = (LPTSTR)(LPCTSTR)arFileTitles.GetAt(i);
cbItem.cchTextMax = 256;
comboBox.InsertItem(&cbItem);
}

comboBox.SetCurSel(0);
}

And here's the code that's called when the FileFind push-button is clicked :

void CFileFinderDlg::OnFindfile()
{
//m_ilImages is the member variable image list object
m_ilImages.Add(AfxGetApp()->LoadIcon(IDR_MAINFRAME));
//m_Combo is a Control variable mapped to an extended combo box
m_Combo.SetImageList(&m_ilImages);

ListSoundFiles(m_Combo,"Sounds","WAV",0);
}

//And there's the code that's called when the Browse button is clicked:

void CFileFinderDlg::OnBrowse()
{
CFileDialog dlg(TRUE,NULL,NULL,OFN_HIDEREADONLY | OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST,
//********BUG seems to be caused by the line below*******
//if you change the extension filter of the File Open dialog
//to All files (*.*)|*.* instead, everything works fine!
"WAV files (*.wav)|*.wav", this);

if(dlg.DoModal() == IDOK)
{
//m_strSoundPath is a Value member variable mapped to the exit box
m_strSoundPath = dlg.GetPathName();

CEdit* pEdit = (CEdit*)GetDlgItem(IDC_EDIT1);
pEdit->SetWindowText(m_strSoundPath);
}
}

If you copy and paste all these into a new MFC dialog-based program and follow the steps, you should see the bug as listed.

For a start, the most elusive bug in the world can only be solved by the most talented programmer.

From Monday onwards, I'm gonna eat Win32 code and deep MFC internals for breakfast, lunch and dinner.

U're the one whom I should thank, Brandon!
Anyway, I found a flag that might help to sove the problem, and I'm pretty sure you know it too :

OFN_NOCHANGEDIR
Restores the current directory to its original value if the user changed the directory while searching for files.
Windows NT 4.0/2000/XP: This flag is ineffective for GetOpenFileName.

As you can see, this flag resets the current directory to it's original value, so it will probably work for my case. The problem is : as listed above, MSDN says this flag is ineffective for NT 4.0, 2000 and XP.

And does that mean that this flag has no effect on these OSes and I gotta code my own code to reset the current directory?

Thanks a lot, Brandon! :):D

Let me be banned, but there's some things which must be done, in the name of our Father, God.
I really wanna express my utmost gratitude and gratefulness to the pure and ole~ mighty Brandon Parker.

Thank you, Brandon! :)