|
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
|
|
|
|
|
Thanks for that!
This class is a SDI application. Why it wasn't designed as a dialog class, I don't know. I inherited this applicaton.
I'll see what I can dig up about the CWnd closing improperly and the this pointer. Gimme a few.
|
|
|
|
|
I have written a class as follows,
class String<br />
{<br />
char *m_string;<br />
unsigned int m_length;<br />
<br />
public :<br />
String(void);<br />
String(char *str);<br />
String(String str);<br />
virtual ~String();<br />
<br />
int GetLength(void);<br />
<br />
void operator=(char *str);<br />
<br />
String operator+(String str);<br />
String operator+(char ch);<br />
String operator+(char *str);<br />
<br />
bool operator==(String str);<br />
bool operator==(char* str);<br />
<br />
bool operator!=(String str);<br />
bool operator!=(char* str);<br />
<br />
String Trim(void);<br />
<br />
void InsertAt(int pos, char ch);<br />
};
for
String obj1("AS"), obj2("qwe");<br />
if( obj1 == obj2 )
if( obj1 == "as" )
But which function should be written to perform operation if( "as" == obj1 )
I was thinking about a '=='operator overloaded frien function. But it generate an error.
Can anyone suggest a better way for this?
When I add constructor as String(String str); It gives compile error as illegal copy constructor. Why? what is solution?
|
|
|
|
|
Aniket Salunkhe wrote: When I add constructor as String(String str); It gives compile error as illegal copy constructor.
Try String(String&& str);
For your overloaded operators, within the function you need to get a handle to your stored string and pass them both into the standard string compare functions i.e.
bool operator==(char* str)<br />
{<br />
return strcmp( str, m_string ) == 0;<br />
}
|
|
|
|
|
WalderMort wrote: String(String&& str);
 twice ?
weren't you thinking to const String& instead ?
|
|
|
|
|
Well, if an address needs and address it wouldn't be const now would it  , sure as hell confuse the post office though.
I have no excuse this time 
|
|
|
|
|
Aniket Salunkhe wrote: But which function should be written to perform operation if( "as" == obj1 )
None.
"as" is a pointer and if you compare the pointer value with an object you will at least get an error similar to "cannot convert obj1 to char*".
You could compose your if-statement as
if( String( "as" ) == obj1 )
Regarding the copy constructor the syntax is this:
String( const String& str ) which should be similar to the syntax of the assignment operator, the difference is that the assignment operator should return a reference to the object to allow statements like
obj1 = obj2 = "MyString";
The assignment operator declaration should look like this:
String& operator=( const char* str );
String& operator=( const String& str );
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Thanks Roger
Roger Stoltz wrote: The assignment operator declaration should look like this:
String& operator=( const char* str ); // For assigning a string, and...
String& operator=( const String& str ); // For assigning another object
why like this?
I have written destructor as
String::~String()<br />
{<br />
free(this->m_string);<br />
this->m_length = 0;<br />
}
And I was tring to write Trim function as follows,
String String::Trim(void)<br />
{<br />
<br />
<br />
String trim_string;<br />
<br />
strcpy(trim_string.m_string, this->m_string);<br />
trim_string.m_length = this->m_length;<br />
<br />
while( trim_string.m_string[--trim_string.m_length] == ' ' );<br />
trim_string.m_string[++trim_string.m_length] = '\0';<br />
<br />
trim_string.m_string = strrev(trim_string.m_string);<br />
<br />
while( trim_string.m_string[--trim_string.m_length] == ' ' );<br />
trim_string.m_string[++trim_string.m_length] = '\0';<br />
<br />
trim_string.m_string = strrev(trim_string.m_string);<br />
<br />
return trim_string;<br />
}
But then it gives Runtime error at "return trim_string;" (OR return *trim_string; ) in Trim(). When when I remove code from Destructor function Runtime error doesn't occur.
What is the wrong?
|
|
|
|
|
Aniket Salunkhe wrote: Roger Stoltz wrote:
The assignment operator declaration should look like this:
String& operator=( const char* str ); // For assigning a string, and...
String& operator=( const String& str ); // For assigning another object
why like this?
Which part is unclear?
This is how the assignment operator should be declared to work as expected.
Regarding your destructor I see that you're mixing memory management routines from both C and C++. Don't ever do that! In C++ you shall use new and delete.
Regarding your Trim function.
A Trim function is expected to trim the object it contains, not returning a trimmed copy of the original object. Personally I would like such a function to return a reference to itself in order to allow the use of cascading, e.g. str.TrimLeft().TrimRight() where TrimRight is called on the reference to the str object returned by TrimLeft.
In order to accomplish this your function should look like this:
String& String::Trim()
{
....
return *this;
}
I suspect that the runtime error you get when calling Trim is due to the abscense of a proper copy constructor. This error will disappear if you rewrite the Trim function as suggested above, but that doesn't mean you shouldn't write a copy constructor; you most certainly should in order to avoid shallow copies.
When you write a class that dynamically allocates memory you should always define at least:
- a default constructor that initializes the internal pointers
- a destructor that deallocates memory
- a copy constructor that make deep copies
- an overloaded assignment operator
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Roger Stoltz wrote: A Trim function is expected to trim the object it contains, not returning a trimmed copy of the original object
I am tring to build 'String' class something similar as in C#, in that it doesn't Trim the object itself ! So what should I follow?
Can you help me to create 'String', because I am getting problem in Copy Constructor & Destructor while returning 'String' object in member function.
Should I show you 'String' class? According to your time, check where I am going wrong in 'String' class. OR else just suggest me any book/link so design a proper class.
Thanks for your Help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
