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.
I would say the WM_SETFONT call is working the reason the last digits are not displaying is because it doesn't have enough room in the box. That is the default behaviour to drop the last word that doesn't fit in the area. Try making the box just a fraction wider or reduce the font size. It's highlighting another issue that the font is coming out slightly different size to before but that is probably not surprising. You could try the height in pixels as a minus sign that tells windows not to round the value to best value but make the value absolute. I don't know what details the original MFC used to select the font but you could look up the code section.
LOGFONT structure (Windows)[^]
< 0 = The font mapper transforms this value into device units and matches its absolute value against the character height of the available fonts.
If that doesn't work MS have a problem because that is a documented API call nothing to do with frameworks etc .. just log it with them as a bug and they will have to fix. It should get a reasonably high priority especially since it is easy to replicate.
I can confirm the problem. Seem to be the Windows Creators Update... Two days ago one of our applications was displaying the date correctly and now it is only displaying a few random pixels. The same application run on a system that has not been updated works as expected. Using the, byte-for-byte, same executable - nothing to do with MFC or changes in the RTL.
EDIT: Adding a manifest with "Microsoft.Windows.Common-Controls" does improve things (apart from the fact that all controls look different, which might be a problem for the odd application) - Microsoft has definitely changed some visual behaviour...
Yes but the API itself behaves correctly it's just frameworks that are breaking and that is fine it is just a framework support issue. The problem now is MFC is no longer a direct Microsoft support framework they have released the sourcecode as it reached end of it's commercial life. It will be interesting to see if they fix it or just tell us we have the sourcecode and we need to go and fix it ... really it isn't their problem anymore and they can wipe there hands of it.
Wonder if it's broken on .NET or WPF I will have to go and have a look later today, their response may differ depending on that.