|
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;
memset(&lf, 0, sizeof(LOGFONT));
lf.lfHeight = 12;
_tcsncpy_s(lf.lfFaceName, LF_FACESIZE, _T("MS Shell Dlg"), _tcslen(_T("MS Shell Dlg")));
HFONT hfont = ::CreateFontIndirect(&lf);
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
modified 19-Apr-17 16:20pm.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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...
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="XYZ, ABC" type="win32" />
<description>ABC</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df' language='*' />
</dependentAssembly>
</dependency>
</assembly>
cu,
Michael
modified 20-Apr-17 7:37am.
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
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
#endif
It works perfectly. The 'new' is smarter and with a cleaner look ... It was finally worth the work
Thierry
www.tgmdev.be
|
|
|
|
|
Can anyone else getting this problem please go to Microsoft Connect number 3129203 and vote it up.
|
|
|
|
|
Fixed 
June 13th Cumulative Update - kb4022725
|
|
|
|
|
Hi
I don't know if this the right place for this i.e. meaning C/C++ Microsoft specific
but I am trying to use the INTEL C/C++ compiler instead of Microsoft
so in win32.mak
I replaced cc = cl with cc = icpc
I checked the PATH
but I still got this error on the makefile build
1>icpc : error #10236: File not found: 'icpc'
|
|
|
|
|
Standard error message. Whatever "icpc" is it does not exist in any of the directories in your PATH environment variable, or Makefile macros.
|
|
|
|
|
Richard
I was looking at benchmarks and it seems for native x86 calls ( non windows services ) the intel compiler produces better code I think the intel compiler on a windows machine though is icl.exe for win32.make I guess as you said it has to be in the path
|
|
|
|
|
I'am a bigenner in cyptology. It's really an interested domain. I have started in cryptography by modifyiong the round function of xtea and by modifying the p-layer of PRESENT. I find it sample but when I will do differential and linear cryptanalysis on them it becomes more difficult because I didn't find a sample example to understand more the principle. Can anyone help me with code c of differential cryptanalysis of PRESENT and XTEA. I will be grateful for you
|
|
|
|
|
Member 13023118 wrote: code c of differential cryptanalysis of PRESENT and XTEA
That is a good question for Google, or Search[^] the CodeProject articles.
|
|
|
|
|
I have searched in different sites but I didn't find any code that can help me
|
|
|
|
|
Then maybe no one has yet written any.
|
|
|
|
|
You didn't look very hard the C code is right there in wikipedia (XTEA - Wikipedia[^])
#include <stdint.h>
void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
unsigned int i;
uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9;
for (i=0; i < num_rounds; i++) {
v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
sum += delta;
v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
}
v[0]=v0; v[1]=v1;
}
void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
unsigned int i;
uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
for (i=0; i < num_rounds; i++) {
v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
sum -= delta;
v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
}
v[0]=v0; v[1]=v1;
}
The C implementation for PRESENT you can get here in 8, 16 or 32 bit ... PRESENT Encryption
In vino veritas
modified 16-Apr-17 10:36am.
|
|
|
|
|
Thanks alot for your help but I have already got it and I also modify xtea round function to become more secure but my problem now is to understand the principle of differential cryptanalysis that's why I need code c of of differential cryptanalysis in both of algorithms xtea and PRESENT
|
|
|
|
|
Okay I am just a boring old programmer you got me intrigued how do you produce code for the differential it would be incredibly long given the statistical spread of the output. I know for example AES is immune to any sort of differential attack if you look at the algorithm you can see why. I can tell you from practical doing it, that it's easier to just brute force attack these things.
That is why I suggest the code doesn't exist
If you want to find out how secure your modification is time the bruteforce attack on it.
In vino veritas
|
|
|
|
|
That is why I suggest the code doesn't exist
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
