below code i used. My problem is more then 5 times i call this function. It shows 'debug assertion error'
finally debug goes here
// all other messages route through message map
CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
Here My Code
TCHAR szFilters= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
// Create an Open dialog; the default file name extension is ".my".
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
// Display the file dialog. When user clicks OK, fileDlg.DoModal()// returns IDOK.if(fileDlg.DoModal() == IDOK)
CString pathName = fileDlg.GetPathName();
// Implement opening and reading file in here.//Change the window's title to the opened file's title.
CString fileName = fileDlg.GetFileTitle();
You did not show the line that asserts so I can only guess that it checks if pWnd is NULL (I have no VS2008 here but it seems that the code snippet is from the AfxWndProc function).
From that line debug backwards to identify the invalid window handle that finally leads to the assertion.
Because your code snippet using the CFileDialog is just a copy of the MSDN example code I guess that the assertion is not related to the file dialog but to some other window or you did not showed the used code.
In the latter case you might try to pass also the pParentWnd to the file dialog.
We have a console application to represent a process plant model. This application has several functions for doing plant calculations. We have defined a structure and a global object for maintaining the data and doing calculations, which is initialized in one of the function. We assign and calculate values for the members of the object by using it in all the corresponding functions.
We have defined a number of functions as shown above which changes the value of each of the members of ETest. Now our requirement is to identify and separate the functions to create a library to abstract it from users of the application.
Now, when I create a static library application and add the files with all the functions, and add the lib in my original application to use the functions, the functions still need to use the same object ETest, which is used in the main application as well. Is there any way to share the structure between the main application and the static library. Can I use the createfilemapping for creating a shared memory to assign values in the main app as well as the static library?
a DLL with it's own copy of the CRT could be using a different version of the CRT than the main app uses. and that will lead to problems if you try to delete/free memory in one place that was allocated in the other.
I have a project that has a CDateTimeCtrl in it. The program worked
fine for years. I ran a long Windows 10 update and now the date time ctrl
displays as // instead of the initial date. Has anyone else come across this
problem and do you have a solution?
Windows 10 update has a new garbage collector. You used to get away with stuff you can't anymore. For a font to be set, it must remain in memory, it can not be a variable font (like on the local stack) that is destroyed directly after setting it. Old code used to work because the old garbage collector was terrible, try it now and your font will be gone bye bye.
The telltale giveaway you did it all wrong is I bet you never deleted the CFONT you made even though you are supposed to and it's your responsibility. The reason you won't have is because when you close the class/dialog or window you no longer have access to the CFONT because it was just some local variable on the stack. Such code is not only bugged it bleeds font handles but "it did used to work".
So lets ask that question does your code delete the Cfont you made?
To make sure your Cfont is valid for the life of it's use, you have 3 options
1.) Place it up in the class, dialog or window data that the font is being used for
2.) Make it a global variable or do a globalalloc
3.) Use SelectObject to put it on a DC that persists for the time you need it
Finally it is your responsibility to clean up and dispose the font when your class/dialog or windows or use of it ends ... you know something like font.DeleteObject();
Basically if this is the problem your old code was always bugged you were just lucky the bug didn't shake out before because the old windows GC was horrible.
Create a new dialog based MFC application. MBCS character set. Put a datetimepicker control on the dialog. Even this tiny sample application will demonstrate the problem.
Customers did report this problem, but until now we couldn't reproduce it at our office.
- If the application is started from "Run as administrator", there is no problem.
- It might be the chosen character set is related. I have only seen it in a MBCS sample, not in a Unicode sample. I am not quite sure about this.
Yeah I take it back MFC is bugged now you can't set any font not just that one ..... just go around the stupidity of MFC and use the Windows API direct
// clear out structure
memset(&lf, 0, sizeof(LOGFONT));
// request a 12-pixel-height font
lf.lfHeight = 12;
// request a face name "MS Shell Dlg"
_tcsncpy_s(lf.lfFaceName, LF_FACESIZE, _T("MS Shell Dlg"), _tcslen(_T("MS Shell Dlg")));
// create the font
HFONT hfont = ::CreateFontIndirect(&lf);
// Send the WM_SETFONT message to the date time control
m_dateTimeCtrl.SendMessage(WM_SETFONT, (WPARAM)hfont, 1);
That works fine and they can't break that or everything would break because it is how you change fonts on any window.
It is even more complicated: if I put the above mentioned tests into one project, it behaves different in comparison to three separated test projects!
This behaviour let me think of some kind of memory corruption (stack?), but I can't pinpoint until now how this can occur in a trivial test application.
Last Visit: 31-Dec-99 18:00 Last Update: 28-May-17 17:31