|
You should just pass the structure by reference to all functions that need to access its content.
|
|
|
|
|
you don't need to do anything special for this. static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
|
|
|
|
|
A DLL gets mapped into the main application's address space, so it effectively has full access also.
|
|
|
|
|
yeah, you're right. i should've phrased that better; i was thinking more along the lines of dynamic CRT, which complicates new/delete.
|
|
|
|
|
I don't see how, it is just allocating space on the heap which is part of the data sections in the address space. If this were an issue then hardly any DLL code would work properly.
|
|
|
|
|
|
Chris Losinger wrote: if you try to delete/free memory in one place that was allocated in the other.
You should be punished severely. In fact you probably will be when your application starts misbehaving.
|
|
|
|
|
Chris Losinger wrote: static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
dlls also get loaded into the process address space and therefore share app memory too. 
|
|
|
|
|
they won't share CRT memory management, however (which is really what i was trying to say).
|
|
|
|
|
Doesnt this depend on the version of CRT you used to build them?
|
|
|
|
|
|
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?
|
|
|
|
|
You need to provide more information. The chances of anyone else having a similar problem AND just happening to read your message, are not likely to be very high.
Also I have deleted your two reposts of this question.
|
|
|
|
|
What does your code look like that populates that control?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
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
modified 18-Apr-17 0:28am.
|
|
|
|
|
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;
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
