|
Thanks so much, I will work on that...
|
|
|
|
|
Hi,
Am using
CFileDialog fileDlg VC++2008 version. Button use to open
CFileDialog below code i used. My problem is more then 5 times i call this function. It shows 'debug assertion error'
File: f:\dd\vc7libs\ship\atlmfc\src\wincore.cpp
line:398
finally debug goes here
CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
Here My Code
TCHAR szFilters[]= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
if(fileDlg.DoModal() == IDOK)
{
CString pathName = fileDlg.GetPathName();
CString fileName = fileDlg.GetFileTitle();
SetWindowText(fileName);
}
|
|
|
|
|
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.
|
|
|
|
|
Hi,
Are you running this code on a Microsoft operating system older than Vista?
If so... this is most likely happening because the once you hit the OK button... the window closes.
The older MFC versions use the SendMessage function[^] and send a CDM_GETSPEC message[^] to the CFileDialog window and get the file name and the CDM_GETFILEPATH message[^] to get the path.
You can potentially avoid this by setting the CFileDialog::m_ofn.lpstrFile[^] member to a local buffer.
Best Wishes,
-David Delaune
|
|
|
|
|
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.
For Eg:
struct plantDB
{
short IMISC_I [300];
char LL1_I [300];
char LL2_I [300];
char MALF_I [300];
char REMP_I [300];
float REM_I [300];
float NXS [30][600];
float VAR_I [1500];
float VART_I [300];
float VRAMP_I [300];
.
.
.
};
plantDB *ETest = new PlantDB;
Sample of the function:
float EULER(int N,int K,int TYPE,float DER,float MAX,float MIN,float FLAG)
{
float FACTOR = 0.0 ;
float EULER;
if ( FLAG ) ETest->VAR_I = 51.0 ;
}
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?
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
