Thanks very much for the reply.
It doesn't seem to be my code though: It seems like a bug in the GetOpenFileName() function. What's happening is the mouse-over tooltip will load once, but then next time the dialog launches, it will crash instead of display the tooltip (for files only, not folders). As far as i know, the OPENFILENAME struct has nothing to do with the tooltips displayed in the Open / Save dialog boxes.
Why did u call ZeroMemory(&ofn, sizeof(OPENFILENAME))
you reset the ofn pointer whitout deleting them.
is it the first and the only initialisation
After the call of ZeroMemory I think that ofn.lpstrDefExt = "glf"; and ofn.lpstrFilter = "Game Level File (*.glf)\0 *.glf\0\0"; are not correctly initialised.
for me ofn.lpstrDefExt and ofn.lpstrFilter are not allocated but you set it to a temporary variables.
Did you try this :
ofn.lpstrDefExt = nex char[MAX_PATH];
strcpy(ofn.lpstrDefExt, "glf");
ofn.lpstrFilter = nex char[MAX_PATH];
strcpy(ofn.lpstrFilter , "Game Level File (*.glf)\0 *.glf\0\0);
dont forget to call delete [] on destruction.
Hi ,
It seems there is no problem in filling the OPENFILENAME structure or calling the GetOpenFileName() function(even the files are on desktop).I tested ur code in my sample.It's working fine.
What i did is , i made OPENFILENAME ofn as private member of dialog class aswell as InitOFN (modified for .txt files)and SetOFN too.And a button_click handler is defined as following .I could n't produce the crashing error u r reporting.Can u simulate the same bug with a sample and post it
============================================
void
CMFCDlgDlg::InitOFN(){
ZeroMemory(&ofn,
sizeof(OPENFILENAME));ofn.lStructSize =
sizeof(OPENFILENAME);ofn.hwndOwner =
this->m_hWnd;;ofn.lpstrFilter = _T(
"Text Files(*.txt)\0 *.txt\0\0");ofn.nFilterIndex = 1;
ofn.lpstrDefExt = _T(
"glf");ofn.nMaxFile = MAX_PATH;
ofn.nMaxFileTitle = MAX_PATH;
}
//============================================================================
// This is called before GetOpenFileName()/GetSaveFileName() is called.
//============================================================================
void
CMFCDlgDlg::SetOFN(int mode){
static WCHAR path_buf[MAX_PATH]; static WCHAR name_buf[MAX_PATH];memset(path_buf,
'\0', sizeof(path_buf));memset(name_buf,
'\0', sizeof(name_buf));ofn.lpstrFile = path_buf;
ofn.lpstrFileTitle = name_buf;
if (mode == OPEN) //here OPEN is enum define dlg.h fileofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
elseofn.Flags = OFN_OVERWRITEPROMPT;
}
void
CMFCDlgDlg::OnBnClickedButton1(){
InitOFN();
SetOFN(OPEN);
GetOpenFileName(&ofn);
MessageBox(ofn.lpstrFile);
}
=================================
Thanx,
Ch.T.GOpi Kumar.
I present to you a very simple program using GetOpenFileName that, like the others, crashes at the tooltip of a file in the second open dialog assuming the tooltip was shown in the previous dialog and that the file is on the desktop.
InitOFN(ofn);
MSG msg = {0};
while (msg.message != WM_QUIT)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
if (GetAsyncKeyState(VK_RETURN) & 0x8000)
{
SetOFN();
GetOpenFileName(&ofn);
}
if (GetAsyncKeyState(VK_ESCAPE) & 0x8000)
msg.message = WM_QUIT;
}
return 0;
ZeroMemory(&ofn, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFilter = "Game Level File\0*.elf\0\0";
ofn.nFilterIndex = 1;
ofn.lpstrDefExt = "glf";
ofn.nMaxFile = MAX_PATH;
ofn.nMaxFileTitle = MAX_PATH;
static char path_buf[MAX_PATH];
static char name_buf[MAX_PATH];
memset(path_buf, '\0', sizeof(path_buf));
memset(name_buf, '\0', sizeof(name_buf));
ofn.lpstrFile = path_buf; // buffer for file name edit control
ofn.lpstrFileTitle = name_buf; // buffer for file title
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
yxrk,
Maybe try putting OPENFILENAME, both its structure and functions in the CALLBACK where I think it belongs in the first place. However, if you really need to open up a file in the WinMain() then it would seem to me that it might be a good idea to know the file's name and where it is in the first place. Otherwise, you may be fishing in a lake before it got filled up with water, not to mention fish. And it would be safer to do this before you got into the WinMain()'s while GetMessage(&msg,,,) loop.
On the other hand, re-doing the WinMain()'s while (GetMessage(&msg,,,,)) loop with PeekMessage(&msg,,,) and such stuff may not be such a hot idea with OPENFILENAME's structure. It¡¯s probably getting hit in the face every other fraction of a second with something from somewhere. If so, then your program's stack might have simply overflowed, which would explain why it has a tendency to crash.
JamesSexton