|
If you are running a release build of an executable and are getting Debug Assertion Fail messages, it sounds like you have a mismatch of binaries somewhere (like a Release EXE using a Debug Lib or DLL).
Generally not a good idea unless you really know what you are doing.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
arunkk1 wrote:
Debug Assertion Failed in 'dlgprop.cpp' the call stack seems to be pointing to the 'ASSERT' line in AddPage function
There are four assertions. Which one?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I'm really not sure what you mean by 'four assertions' but it was pointing to this line 'in AddPage() ASSERT_KINDOF(CPropertyPage, pPage);'
As far as having a 'Debug Assertion Failure' in release mode, I have debugging info turned on in project properties...
Thanks
|
|
|
|
|
arunkk1 wrote: As far as having a 'Debug Assertion Failure' in release mode, I have debugging info turned on in project properties...
I do not believe that will turn on the ASSERT/ASSERTE macros (they require the _DEBUG preprocessor def to be #defined), which are what you are seeing getting triggered.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
arunkk1 wrote: I'm really not sure what you mean by 'four assertions'...
The first four statements in the CPropertyPage::AddPage() method are assertions. The one in question is telling you that your property page is not derived from CPropertyPage.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I moved to UNIX/Java world mostly few years ago. Used to know Windows.
Remember there was a Windows function to limit desktop area size, so one may a dock his dialog app on a side and may it visible permanent.
Anybody may kick me in right direction?
Thanks.
Life is difficult, but luckily is short.
|
|
|
|
|
|
Thanks.
|
|
|
|
|
I am attempting to patch my software for the upcoming Daylight Saving Time (DST) changes, where for example the Spring DST transition is now on March 11, 2007 instead of April 1. I was running some test code using mktime() under Visual Studio 6.0 and Visual Studio 2005 and it looks like mktime() was still treating April 1, 2007 as the DST transition day.
I am running Windows XP sp2, with all the latest critical fixes installed. VS6 has the latest service packs on it and a fairly late Core SDK installed. VS2005 is the original install without service pack 1 installed.
Does anyone know if/when/where the updates for Win32 APIs such as mktime() are going to be available, or if I am missing something here?
Thanks for any help you can give! I am installing sp1 for VS2005 soon and will report back with my findings. Here is the sample code that I use in VS6 or VS2005, and in both cases I get "diff days: 0, (total seconds: 82800)", where I would expect "1" and "86400" if April 1, 2007 was just any other day:
<br />
struct tm a, b;<br />
time_t ta, tb;<br />
CTimeSpan diff;<br />
CString csTemp;<br />
<br />
memset(&a, 0, sizeof(a));<br />
memset(&b, 0, sizeof(b));<br />
<br />
a.tm_mon = 3;<br />
a.tm_mday = 1;<br />
a.tm_year = 2007 - 1900;<br />
a.tm_isdst = -1;<br />
<br />
b.tm_mon = 3;<br />
b.tm_mday = 2;<br />
b.tm_year = 2007 - 1900;<br />
b.tm_isdst = -1;<br />
<br />
ta = mktime(&a);<br />
tb = mktime(&b);<br />
<br />
diff = CTimeSpan(tb) - CTimeSpan(ta);<br />
<br />
csTemp.Format("diff days: %d, (total seconds: %d)", diff.GetDays(), diff.GetTotalSeconds());<br />
MessageBox((LPCTSTR)csTemp);<br />
|
|
|
|
|
See here.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks so much for your reply. Installing the KB928388 update did in fact fix this problem. I had "assumed" that this important DST update was already in the MS Windows critical fixes which I had already installed, further reading the notes says that it is optional for now, and will hit critical status once they work out some bugs with Outlook 2003 and the DST changes.
Thanks again!
|
|
|
|
|
Hi,
first, I don't think I'm capable of providing the necessary information up front for the answer to my question so I'll really only be asking for links to enable me to educate myself a little further.
how can I trace back a problem associated with an assertion failure in wincore.cpp (line 1143). (Windows CE, BTW.)
Basically, I'm calling a dialog from a menu item and when the dialog is closed (either IDOK or IDCANCEL) the assertion is thrown. I've checked certain variables but their values appear OK.
One debugging message I'm getting is:
Assertion Failed: {Appname}: File wincore.cpp. line 1143
Warning: calling DestroyWindow in CWnd::~CWnd; OnDestroy or PostNcDestroy in derived class will not be called.
{rinse/repeat 5 more times.
|
|
|
|
|
Is this with a modeless dialog? Are you calling EndDialog() at any point? Have you overridden either OnOK() or OnCancel()?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
OK, here's what happening in the view class:
<br />
void CCEGUIView::OnOptionsSettings() <br />
{<br />
CRecSetupDlg dlg;<br />
dlg.m_bMinutes = m_bMinutes;
<br />
int iResult = dlg.DoModal();<br />
if(iResult == IDOK)<br />
{<br />
m_bMinutes = dlg.m_bMinutes;<br />
}<br />
}<br />
EndDialog() is not being called in the CCEGUIView::OnOptionsSettings() function.
EndDialog() *is* being called in the CRecSetupDlg::OnOK() function.
In the CRecSetupDlg class, OnOK() is over-ridden and EndDialog(IDOK) is called as the last statement in the OnOK() function.
OnCancel() is not over-ridden - in fact, it's not displayed in the code - the default is being used. Pressing 'CANCEL' or 'OK' causes the assertion fault.
|
|
|
|
|
When the assertion fires, look at the stack window to see where the assertion came from (before wincore.cpp).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I walked the entire stack for this problem by setting a breakpoint inside my CRecSetupDlg::OnOK() function.
Here's the entire stack before the assertion, I'm going to walk it again looking for the ASSERT() macro:
<br />
CRecSetupDlg::OnOK(CString {"?Æ?"}) line 193<br />
<br />
_AfxDispatchCmdMsg(CCmdTarget * 0x2a07eec0 {CCmdTarget}, unsigned int 1, int 0, void (void)* 0x00bc1354 [thunk]:`vcall'{196,{flat}}' , void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88<br />
<br />
CCmdTarget::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000, unsigned int 273) line 302 + 52 bytes<br />
<br />
CDialog::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000, CWnd * 0x00c566ac CThreadLocal<class _AFX_THREAD_STATE>::CreateObject(void)) line 101 + 28 bytes<br />
<br />
CWnd::OnCommand(unsigned int 1, long 1231936, HWND__ * 0x0012cc40) line 2273<br />
<br />
CWnd::OnWndMsg(unsigned int 273, unsigned int 1, long 1231936, long * 0x2a07e970, long 0) line 1774 + 32 bytes<br />
<br />
CWnd::WindowProc(unsigned int 273, unsigned int 1, long 1231936, long 0) line 1762 + 44 bytes<br />
<br />
AfxCallWndProc(CWnd * 0x2a07eec0 {CWnd hWnd=0x0012ca20}, HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 233 + 36 bytes<br />
<br />
AfxWndProc(HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 398 + 28 bytes<br />
<br />
AfxWndProcBase(HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 236 + 20 bytes<br />
<br />
800453b0()<br />
Earlier, I walked it all the way back to AfxWndProcBase(...) and that's where the assertion failure happened - well, was reported anyway. Then, after entering that function, the IDE crashed and my link was broken.
{{sidebar: What's the last function: '800453b0()'? Is that the address of calling function/class? }}
|
|
|
|
|
But you need to examine the call stack after the assertion fires, not before.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
elementary dear Watson 
|
|
|
|
|
The resource file is used to reference unique IDs for form data, right? Therefore, there should be exactly _zero_ ID reference #'s that repeat, correct?
Here's my resource.h file - note that repeating numbers are the only ones displayed here; sequential numbered items are removed for brevity's sake.
<br />
#define IDR_RECORDING_TOOLBAR 130<br />
#define IDD_DATALIST 130<br />
#define IDD_MULT_MODBIN_LIST 160<br />
#define IDD_MOD_SELECT_DLG 160<br />
#define IDD_DIALOG3 165<br />
#define IDD_DATA_ITERATOR_DLG 165<br />
#define IDC_MIL 1001<br />
#define IDC_LIST_AVAILABLE 1001<br />
#define IDC_COMBO1 1016<br />
#define IDC_SPECIFIC_CODE_COMBO 1016<br />
#define IDC_TRIGGER_COMBO 1016<br />
#define IDC_COMBO_CATEGORY 1016<br />
#define IDC_CMBO_APPLICATION 1016<br />
#define IDC_COMBO3 1017<br />
#define IDC_COMBO_DOWN 1017<br />
#define IDC_MIN_COMBO 1017<br />
#define IDC_COMBO2 1018<br />
#define IDC_COMBO_APPLICATION 1018<br />
#define IDC_CMBO_CATEGORY 1018<br />
#define IDC_BUTTON1 1022<br />
#define IDC_GET_DTC 1022<br />
#define IDC_BTN_ADD 1022<br />
#define IDC_BTN_ITEMCHECK 1022<br />
#define IDC_BUTTON2 1023<br />
#define IDC_BTN_REMOVE 1023<br />
#define IDC_BUTTON3 1024<br />
#define IDC_BTN_REMOVEALL 1024<br />
#define IDC_CUSTOMDL 1029<br />
#define IDC_BUTTON4 1029<br />
#define IDC_CDL_ALL 1030<br />
#define IDC_BUTTON5 1030<br />
#define IDC_CDL_ADDED 1032<br />
#define IDC_BUTTON7 1032<br />
#define IDC_ADD 1034<br />
#define IDC_BUTTON9 1034<br />
#define IDC_REMOVE 1035<br />
#define IDC_BUTTON10 1035<br />
#define IDC_MONITOR_LIST 1047<br />
#define IDC_SAVE_CDL2 1047<br />
#define IDC_OK_CDL 1047<br />
#define IDC_TIMER 1048<br />
#define IDC_ADD_ALL 1048<br />
#define IDC_REMOVE_ALL2 1049<br />
#define IDC_RESTORE_DEFAULT 1049<br />
#define IDC_TREE1 1100<br />
#define IDC_TREE_DIR 1100<br />
#define ID_BUTTON32782 32782<br />
#define ID_PAUSE 32782<br />
<br />
#ifdef APSTUDIO_INVOKED<br />
#ifndef APSTUDIO_READONLY_SYMBOLS<br />
#define _APS_NEXT_RESOURCE_VALUE 175<br />
#define _APS_NEXT_COMMAND_VALUE 32797<br />
#define _APS_NEXT_CONTROL_VALUE 1102<br />
#define _APS_NEXT_SYMED_VALUE 101<br />
#endif<br />
#endif<br />
<br />
Could this cause me assertion problems? If so, how? I think I know; I just want to hear someone else say it. 
{Sidebar: Note that 'IDC_TREE1' & 'IDC_TREE_DIR' were deleted over two weeks ago.}
|
|
|
|
|
I don't know about causing assertions, but one thing that could easily happen is for the code to reference IDC_BTN_REMOVE and the dialog template to contain IDC_BUTTON3. Since both IDs exist, the compiler is happy. This would likely result in an assertion in the window's DoDataExchange() method, not at closing.
In any case, it might be worth the effort to clean up your project's resource.h file by removing unused IDs and maing the remaing ones sequential.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yeah, when I saw that file a very loud klaxon rang in my head and a trekkie yelled, "Red Alert!"
That's what my work-mate and I concluded, also - cleaning it up. I was going to look around on Microsoft's site to see if any tools exist to do a more exhaustive 'cleansing' of resource files followed up by reviewing sourceforge, too. If none exist, I may make one of my own.
Also, another screwed up issue with this project is that every time I edit/create a form and save, I have to enter into the .RC file with a plain text editor and change the project name from something I think the project *used* to be named to what it is named today. After that, I have to switch back to eVC and let it detect the changes. It's very screwed up. If I knew what was causing that one section to be renamed, I'd fix it. Too late and I'm too tired to access the code tonight. *That's* another topic! 
Hey, thanks for all your help today!!  ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Carl
|
|
|
|
|
Like2Byte wrote: ...any tools exist to do a more exhaustive 'cleansing' of resource files...
Yes, such tools exist.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
You're not calling the base class OnOk() from your override are you?
Mark
|
|
|
|
|
Do you mean calling OnOK() from within OnOK()? If so, no.
The view class uses the default (vanilla) OnOK() function.
The CRecSetupDlg class overrides the OnOK() function and calls EndDialog(IDOK) as the last statement in the OnOK() function.
|
|
|
|
|
What view class? I didn't see that mentioned before
The warning assertion you posted is because of closing a CWnd improperly - It should be done in
two steps, one for the windows object (HWND) and one for the C++ object (CWnd).
If you break in the debugger at the assertion and quickwatch the "this" pointer, what type
is the window. It sounds like it's coming from a different window than the modal dialog.
BTW, I've never coded for CE so hopefully I'm not way off here
Mark
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
