Assertion in afxwin.inl line 24.
in [MFC]
|
From: ggurubasavaraja on 27 Dec 2007 23:53 Hi Folks, I am getting this strange assertion(Assertion in afxwin1 line 24) in my code after the following call stack. Where Command_Formate is my class derived from Cproperty page. Command_Formate::Command_Formate() : CPropertyPage(Command_Formate::IDD,IDS_NA_TESTTOOL) { } CPropertyPage::CPropertyPage(UINT nIDTemplate, UINT nIDCaption, DWORD dwSize) { .. .. CommonConstruct(MAKEINTRESOURCE(nIDTemplate), nIDCaption); } ********* in this function lpszTemplateName is having a <bad pointer> ********* void CPropertyPage::CommonConstruct(LPCTSTR lpszTemplateName, UINT nIDCaption) { m_psp.dwFlags = PSP_USECALLBACK; if (lpszTemplateName != NULL) m_psp.hInstance = AfxFindResourceHandle(lpszTemplateName, RT_DIALOG); .. .. .. } One thing I noticed is when I run my code with the option (use mfc in a shared dll) I don't see these assertions displayed but when I run these with the option(use mfc in a static library ) I get to see the assertions . Do I have to set some option to hide the assertions or is there anything wrong with the code ? Regards, JLD
From: James Simpson on 28 Dec 2007 09:07 Dear JLD, There are a couple of ways to turn of the throwing of assertions, some of them most newsgroup members would think is disgusting, and others may approve of. The way that I use to turn off assertions is to set my MFC project to Release mode. In Visual C++, setting a project to Release mode disables all of the macros in code (both yours and Microsoft) that perform safety checks upon your code (such as throwing that assertion). There is likely some reason why the assertion was called, and it was likely your fault, however setting the project to release mode could very likely turn off this assertion. Here is something else to think about: What happens when you statically link MFC libraries? You mentioned that the assertion is not thrown if you use the shared model of linking MFC in versus statically linking MFC. It seems to me that this is likely at the root of the problem, as you have mentioned. Sometimes even the best linkers can miscalculate what components of the MFC libraries you "need" inside of your exe, and can omit something that can later cause an assertion to be thrown! There is something which your application needs in MFC, that linker cannot figure out! Use as shared library likely fixes this error because when your app runs with this, Windows can pick and choose whatever libraries it needs. A couple things to look at include seeing if the controls/componenets you are using require an additional .lib file to be included in at link time (some do infact require that if you must use static linking). Another helpful thin to do is to build the app using shared MFC libraries and then run Depends, an app that comes with Visual Studio, on your program. This application will tell you what DLLs you are using as you run your app. If you check online, you will find out how to use the Depends app if you don't know how to. The full name of the app from Microsoft is Dependency Walker. By knowing what DLLs you app uses, you can quickly find out where the linker is failing! This is the theory that your app is failing becacuse the linker is omitting key libraries. Regards, James Simpson Straightway Technologies Inc. "ggurubasavaraja(a)gmail.com" wrote: > Hi Folks, > > I am getting this strange assertion(Assertion in afxwin1 line 24) in > my code after the following call stack. > > > Where Command_Formate is my class derived from Cproperty page. > > > Command_Formate::Command_Formate() > : CPropertyPage(Command_Formate::IDD,IDS_NA_TESTTOOL) > { > > } > > CPropertyPage::CPropertyPage(UINT nIDTemplate, UINT nIDCaption, DWORD > dwSize) > { > .. > .. > CommonConstruct(MAKEINTRESOURCE(nIDTemplate), nIDCaption); > } > > ********* > in this function lpszTemplateName is having a <bad pointer> > > ********* > > void CPropertyPage::CommonConstruct(LPCTSTR lpszTemplateName, UINT > nIDCaption) > { > m_psp.dwFlags = PSP_USECALLBACK; > if (lpszTemplateName != NULL) > m_psp.hInstance = AfxFindResourceHandle(lpszTemplateName, > RT_DIALOG); > > .. > .. > .. > } > One thing I noticed is when I run my code with the option (use mfc in > a shared dll) I don't see these assertions displayed but when I run > these with the option(use mfc in a static library ) I get to see the > assertions . > > > Do I have to set some option to hide the assertions or is there > anything wrong with the code ? > > > Regards, > JLD > > >
From: Joseph M. Newcomer on 28 Dec 2007 18:42 If you get assertions, your program is wrong, and you have to fix it. "Hiding" assertions is a nonsensical request. The way you hide them is to fix the bug. Apparently, you are getting a NULL instance handle. But there is no context you provided to suggest when this actually happens, or under what conditions from your program. There are fascinating things that stop working if you use static linking, but understanding what is going wrong requires a lot more context than you have given. The most likely cause is that you have a bad pointer, which is reported, but you didn't go back any further to show the code you were using to do the call, which is critical. joe On Thu, 27 Dec 2007 20:53:18 -0800 (PST), ggurubasavaraja(a)gmail.com wrote: >Hi Folks, > >I am getting this strange assertion(Assertion in afxwin1 line 24) in >my code after the following call stack. > > >Where Command_Formate is my class derived from Cproperty page. > > >Command_Formate::Command_Formate() > : CPropertyPage(Command_Formate::IDD,IDS_NA_TESTTOOL) >{ > >} > >CPropertyPage::CPropertyPage(UINT nIDTemplate, UINT nIDCaption, DWORD >dwSize) >{ >. >. >CommonConstruct(MAKEINTRESOURCE(nIDTemplate), nIDCaption); >} > >********* >in this function lpszTemplateName is having a <bad pointer> > >********* > >void CPropertyPage::CommonConstruct(LPCTSTR lpszTemplateName, UINT >nIDCaption) >{ > m_psp.dwFlags = PSP_USECALLBACK; > if (lpszTemplateName != NULL) > m_psp.hInstance = AfxFindResourceHandle(lpszTemplateName, >RT_DIALOG); > >. >. >. >} >One thing I noticed is when I run my code with the option (use mfc in >a shared dll) I don't see these assertions displayed but when I run >these with the option(use mfc in a static library ) I get to see the >assertions . > > >Do I have to set some option to hide the assertions or is there >anything wrong with the code ? > > >Regards, >JLD > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: ggurubasavaraja on 2 Jan 2008 00:06 Thanks a ton for th replies . In my application's InitInstance() I create the object of Command_formate and add it to a property sheet. And hence the constructor of the class gets called . CTreePropSheet sht(_T("Preferences")); //Where CTreePropSheet is the class dervied from CProperty sheet Command_Formate objCommandFromate; // sht.AddPage(&objCommandFromate); Regards, JLD
From: Joseph M. Newcomer on 2 Jan 2008 02:48 Still not enough information to go on. For example, if you declare a variable like this in your InitInstance handler, the property sheet will be deleted as soon as you leave InitInstance, so who knows what kind of errors will occur after that? Such a program would be incorrect. But you still haven't really shown enough context. joe On Tue, 1 Jan 2008 21:06:31 -0800 (PST), ggurubasavaraja(a)gmail.com wrote: >Thanks a ton for th replies . > >In my application's InitInstance() I create the object of >Command_formate and add it to a property sheet. >And hence the constructor of the class gets called . > > >CTreePropSheet sht(_T("Preferences")); //Where CTreePropSheet is the >class dervied from CProperty sheet >Command_Formate objCommandFromate; // > >sht.AddPage(&objCommandFromate); > > >Regards, >JLD Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Next
|
Last
Pages: 1 2 Prev: CListBoxGetItemDataPtr and dynamic cast Next: Tab Control without Proprety Page? |