CDateTimeCtrl in Windows 10
-
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.
In vino veritas
Leon, Sorry, but I don't think this is the problem. 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. Related is: - 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.
-
Leon, Sorry, but I don't think this is the problem. 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. Related is: - 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
LOGFONT lf;
// 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.
In vino veritas
-
Leon, Sorry, but I don't think this is the problem. 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. Related is: - 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.
Hi, 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...
ABCcu, Michael
-
Hi, 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...
ABCcu, Michael
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.
In vino veritas
-
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
LOGFONT lf;
// 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.
In vino veritas
Leon, Thanks, you are right, this is related. And, indeed, it improves the result, but it is still not how it was before the installation of the Windows 10 creator update. We tried the following: - Your code, with CreateFont it will show the date as "21- 4 - ". The year is not visible - m_dateTimeCtrl.SetFont(GetFont()); it will show the date as "21- 4 - 2017". The string is right aligned in the control - m_dateTimeCtrl.SetFormat( _T("dd'-'MM'-'yyyy")); This gives the best result, but is not really an option, because it overrides the system settings for the shortdate presentation
-
Leon, Thanks, you are right, this is related. And, indeed, it improves the result, but it is still not how it was before the installation of the Windows 10 creator update. We tried the following: - Your code, with CreateFont it will show the date as "21- 4 - ". The year is not visible - m_dateTimeCtrl.SetFont(GetFont()); it will show the date as "21- 4 - 2017". The string is right aligned in the control - m_dateTimeCtrl.SetFormat( _T("dd'-'MM'-'yyyy")); This gives the best result, but is not really an option, because it overrides the system settings for the shortdate presentation
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.
-
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.
In vino veritas
-
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.
In vino veritas
-
Hi, 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...
ABCcu, Michael
I think there's a typo and the 2nd one should be "*" rather than "'*'" ? Thanks, it's not feasible to replace old software on all customer sites. Adding the manifest file and setting the reg key below to make it be used gives us an option in case Microsoft decide not to fix it. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide PreferExternalManifest 1
-
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?
Can anyone else getting this problem please go to Microsoft Connect number 3129203 and vote it up.
-
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.
In vino veritas
Sorry, this doesn't solve the problem. On different Windows 10 creator update PC's, we get different results, all of them are incorrect.
-
Sorry, this doesn't solve the problem. On different Windows 10 creator update PC's, we get different results, all of them are incorrect.
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.
In vino veritas
-
Leon, Sorry, but I don't think this is the problem. 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. Related is: - 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.
Hello I faced the same problem .. I decided to go to 64 bits Unicode (with a lot of work to migrate to Unicode) and add the following lines to stdafx.h
#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endifIt works perfectly. The 'new' is smarter and with a cleaner look ... It was finally worth the work Thierry www.tgmdev.be
-
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?
Fixed :) June 13th Cumulative Update - kb4022725
-
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.
In vino veritas
The problem is solved in Microsoft's update of June.