Prev: CArray help
Next: Multithreading
From: Joseph M. Newcomer on 7 May 2010 12:11
If you are calling SetWindowText before the dialog is fully created, you will see the
failure you have described. Therefore, you must override OnInitDialog and not call
SetWindowText until you are in OnInitDialog.

Not knowing what you are trying to do makes it hard.

You should really indicate the version of VS you are using so we can tell you how to set
up the symbols so you get meaningful return addresses in the stack backtrace.

In addition, that WPARAM value is suspect; a WPARAM of 0 MIGHT mean a NULL handle. But
without knowing what you were doing or trying to do, there is no way to guess what is
going on.
joe

On Fri, 7 May 2010 00:57:44 -0700 (PDT), shyam gupta <shyamguptadce(a)gmail.com> wrote:

>Here is the call stack. Plz let me know if u can spot any problem
>
>Thanks
>
>==========================================================
>> mfc71ud.dll!_AfxCommDlgProc(HWND__ * hWnd=0x00040eae, unsigned int message=49265, unsigned int wParam=0, long lParam=28974056) Line 80 + 0x16 C++
> user32.dll!77d48709()
> user32.dll!77d54ca6()
> user32.dll!77d70494()
> user32.dll!77d54af2()
> user32.dll!77d54d1c()
> user32.dll!77d48709()
> user32.dll!77d487eb()
> user32.dll!77d70494()
> user32.dll!77d4b368()
> user32.dll!77d70494()
> user32.dll!77d4b3b4()
> ntdll.dll!7c90e473()
> user32.dll!77d494e3()
> user32.dll!77d4c0de()
> user32.dll!77d4b7ab()
> comdlg32.dll!763b99d3()
> comdlg32.dll!763b7558()
> comdlg32.dll!763dc029()
> comdlg32.dll!763dd459()
> comdlg32.dll!763dd9e9()
> comdlg32.dll!763dda6a()
> shell32.dll!7caa18b3()
> shell32.dll!7caa9f33()
> shell32.dll!7ca49365()
> ntdll.dll!7c94b1be()
> ntdll.dll!7c94b1be()
> ntdll.dll!7c9261dc()
> ntdll.dll!7c926256()
> ntdll.dll!7c9261dc()
> ntdll.dll!7c926256()
> ntdll.dll!7c96e57f()
> ntdll.dll!7c926256()
> ntdll.dll!7c96f888()
> ntdll.dll!7c91ae19()
> ntdll.dll!7c91aa2b()
> ntdll.dll!7c9101db()
> ntdll.dll!7c96f86c()
> ntdll.dll!7c94bc5a()
> ntdll.dll!7c926256()
> ntdll.dll!7c96f86c()
> ntdll.dll!7c94bc5a()
> ntdll.dll!7c926256()
> user32.dll!77d70494()
> user32.dll!77d4b373()
> user32.dll!77d4b3b4()
> user32.dll!77d4b3c4()
> ntdll.dll!7c96f86c()
> ntdll.dll!7c94bc5a()
> ntdll.dll!7c926256()
> shell32.dll!7c9f1f1b()
> shell32.dll!7c9f1f1b()
> shell32.dll!7c9f1d8d()
> ntdll.dll!7c91005d()
> user32.dll!77d70494()
> ntdll.dll!7c926256()
> ntdll.dll!7c926045()
> ntdll.dll!7c91005d()
> ntdll.dll!7c9171c8()
> ntdll.dll!7c9101db()
> ntdll.dll!7c9170a8()
> ntdll.dll!7c916fc7()
> ntdll.dll!7c917126()
> kernel32.dll!7c80a671()
> shell32.dll!7c9f1e01()
> user32.dll!77d48709()
> user32.dll!77d487eb()
> user32.dll!77d70494()
> user32.dll!77d4b368()
> user32.dll!77d70494()
> user32.dll!77d4b3b4()
> ntdll.dll!7c90e473()
> user32.dll!77d494e3()
> user32.dll!77d4de6e()
> user32.dll!77d4b7ab()
> comctl32.dll!773eaf7b()
> user32.dll!77d484bc()
> user32.dll!77d4b8b6()
> user32.dll!77d4b813()
> comctl32.dll!7741ff1d()
> comctl32.dll!774202c2()
> comctl32.dll!77420cf5()
> user32.dll!77d4c034()
> ntdll.dll!7c917126()
> kernel32.dll!7c80a6ad()
> shell32.dll!7c9f1e38()
> shell32.dll!7c9f1e15()
> user32.dll!77d48709()
> user32.dll!77d48bb1()
> user32.dll!77d48832()
> user32.dll!77d487ff()
> user32.dll!77d48709()
> user32.dll!77d487eb()
> user32.dll!77d4ecd2()
> user32.dll!77d70494()
> user32.dll!77d489a5()
> user32.dll!77d553a0()
> user32.dll!77d70494()
> user32.dll!77d489e8()
> user32.dll!77d6e819()
> user32.dll!77d6e956()
> mfc71d.dll!COleControl::OnSetText(unsigned int wParam=1983578112,
>long lParam=428037072) Line 628 + 0x8 C++
> user32.dll!77d568cc()
> user32.dll!77d625b3()
> comdlg32.dll!763b35de()
> comdlg32.dll!763b33e5()
> comdlg32.dll!763b33bc()
> user32.dll!77d48709()
> comdlg32.dll!763c7cc7()
>==========================================================
>
>On May 7, 2:15�am, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
>> The code you showed is fundamentally uninteristing. �The callback on the stack would be
>> far more useful, because it would tell us how you got to the failed condition.
>>
>> I woud suggest that you post the stack callback.
>> � � � � � � � � � � � � � � � � joe
>>
>>
>>
>> On Thu, 6 May 2010 06:24:17 -0700 (PDT), shyam gupta <shyamgupta...(a)gmail.com> wrote:
>> >I have created a customzied CfileDialog dialog box by attaching a
>> >child dialog to it using the hook procedure (OFNHookProc (....) ). Now
>> >that child dialog also has a browse button that also uses CfileDialog
>> >to select another file. This �is done in repsonse to the WM_COMMAND
>> >message. The creation of �the modal dialog box is fine. It does all
>> >the operations �for selecting the file but when I select the concerned
>> >file and press the open button then the application crashes and the
>> >control goes to objcore.cpp as shown below
>>
>> >BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
>> >{
>> > � �ASSERT(this != NULL);
>> > � �// it better be in valid memory, at least for CObject size
>> > � �ASSERT(AfxIsValidAddress(this, sizeof(CObject)));
>>
>> > � �// simple SI case
>> > � �CRuntimeClass* pClassThis = GetRuntimeClass();
>> > � �return pClassThis->IsDerivedFrom(pClass);
>> >}
>>
>> >It is not able to � ASSERT(this != NULL); statement and hence the
>> >application crashes.
>>
>> >I am not able to figure out the exact cause of the error.
>>
>> >Thanks,
>> >Shyam
>>
>> Joseph M. Newcomer [MVP]
>> email: newco...(a)flounder.com
>> Web:http://www.flounder.com
>> MVP Tips:http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 | 
Pages: 1
Prev: CArray help
Next: Multithreading