Prev: Error writing file: VS2005
Next: deploying mfc-based ActiveX control (VC++ 2005)
From: tomasu on 14 Jan 2007 22:32
It looks like not finding the root cause of my previous assert
(afxwin1.inl Line 24) is coming back to bite me.

I got the previous function working fine, but as soon as I moved on to
add my next feature, I got the same exact assertion failure in the same
exact place! Here is my latest function:

void MyMainDlg::OnBnClickedTestlog()
{
ShellExecute(NULL, "open", "TestReport.txt", NULL, NULL,
SW_SHOWNORMAL);
}

Again, I get the assertion failure as soon as my project executes
(before I even call OnBnClickedTestlog).

Commenting out the 'ShellExecute' line causes the assertion to go away.
When running my release build, this function works flawlessly. It
opens 'TestReport.txt' for me in notepad which is what I would expect.

It seems like there is something inherently wrong with my build
configuration or the order of my include statements... Am I way off
track? I have been searching for hours and haven't gotten any closer
to figuring this out. Please help!

From: Doug Harrison [MVP] on 14 Jan 2007 23:25
On 14 Jan 2007 19:32:04 -0800, tomasu(a)gmail.com wrote:

>It looks like not finding the root cause of my previous assert
>(afxwin1.inl Line 24) is coming back to bite me.
>
>I got the previous function working fine, but as soon as I moved on to
>add my next feature, I got the same exact assertion failure in the same
>exact place! Here is my latest function:
>
>void MyMainDlg::OnBnClickedTestlog()
>{
> ShellExecute(NULL, "open", "TestReport.txt", NULL, NULL,
>SW_SHOWNORMAL);
>}
>
>Again, I get the assertion failure as soon as my project executes
>(before I even call OnBnClickedTestlog).

OK.

>Commenting out the 'ShellExecute' line causes the assertion to go away.

But according to your previous sentence, you haven't called
OnBnClickedTestLog before observing the assertion, so how can commenting
this out have any effect?

> When running my release build, this function works flawlessly. It
>opens 'TestReport.txt' for me in notepad which is what I would expect.

Assertions go away in release builds, so the problem likely remains but is
not so overt that you notice it, at least not right away.

>It seems like there is something inherently wrong with my build
>configuration or the order of my include statements... Am I way off
>track? I have been searching for hours and haven't gotten any closer
>to figuring this out. Please help!

What is the text of the assertion? What is the compiler version? What does
the call stack look like when the assertion occurs?

--
Doug Harrison
Visual C++ MVP
From: Alexander Grigoriev on 15 Jan 2007 00:00
If you're using VC 6.0, check that all your ON_MESSAGE handlers have proper
argument signature. They should have exactly TWO arguments, of WPARAM and
LPARAM type.
VC 7.0+ compilers issue an error message in the arguments mismatch.

<tomasu(a)gmail.com> wrote in message
news:1168831924.358049.217420(a)51g2000cwl.googlegroups.com...
> It looks like not finding the root cause of my previous assert
> (afxwin1.inl Line 24) is coming back to bite me.
>
> I got the previous function working fine, but as soon as I moved on to
> add my next feature, I got the same exact assertion failure in the same
> exact place! Here is my latest function:
>
> void MyMainDlg::OnBnClickedTestlog()
> {
> ShellExecute(NULL, "open", "TestReport.txt", NULL, NULL,
> SW_SHOWNORMAL);
> }
>
> Again, I get the assertion failure as soon as my project executes
> (before I even call OnBnClickedTestlog).
>
> Commenting out the 'ShellExecute' line causes the assertion to go away.
> When running my release build, this function works flawlessly. It
> opens 'TestReport.txt' for me in notepad which is what I would expect.
>
> It seems like there is something inherently wrong with my build
> configuration or the order of my include statements... Am I way off
> track? I have been searching for hours and haven't gotten any closer
> to figuring this out. Please help!
>


From: tomasu on 15 Jan 2007 07:45
Text of the ASSERT:

_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
{ ASSERT(afxCurrentResourceHandle != NULL);
return afxCurrentResourceHandle; }

*********************

Call Stack:

mfc80d.dll!AfxGetResourceHandle() Line 24 + 0x1e bytes C++
mfc80d.dll!AfxFindResourceHandle(const char * lpszName=0x00000094,
const char * lpszType=0x00000005) Line 239 + 0x5 bytes C++
mfc80d.dll!CPropertyPage::CommonConstruct(const char *
lpszTemplateName=0x00000094, unsigned int nIDCaption=0) Line 128 + 0xb
bytes C++
mfc80d.dll!CPropertyPage::CPropertyPage(unsigned int nIDTemplate=148,
unsigned int nIDCaption=0, unsigned long dwSize=52) Line 96 C++
HWDiags.exe!TAB_ICAM2::TAB_ICAM2() Line 29 + 0x53 bytes C++
HWDiags.exe!`dynamic initializer for 'ICAM2_Dlg''() Line 31 + 0x28
bytes C++
msvcr80d.dll!_initterm(void (void)* * pfbegin=0x004a04b0, void
(void)* * pfend=0x004a05cc) Line 855 C
HWDiags.exe!__tmainCRTStartup() Line 501 + 0xf bytes C
HWDiags.exe!WinMainCRTStartup() Line 403 C
kernel32.dll!7c816fd7()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]

*********************

>Commenting out the 'ShellExecute' line causes the assertion to go away.

>>But according to your previous sentence, you haven't called
>>OnBnClickedTestLog before observing the assertion, so how can commenting
>>this out have any effect?

That's the same thing I'm wondering! It seems like just compiling this
line causes an ASSERT on program startup.

*********************

I am running Visual Studio 2005. I upgraded this project from VS6
about a month ago and haven't run into any problems like this until
now.

*********************

>>If you're using VC 6.0, check that all your ON_MESSAGE handlers have proper
>>argument signature. They should have exactly TWO arguments, of WPARAM and
>>LPARAM type.
>>VC 7.0+ compilers issue an error message in the arguments mismatch.

I took a quick look and I believe everything here is ok... Here is the
AFX_MSG_MAP of the offending dialog:

BEGIN_MESSAGE_MAP(CHWDiagsDlg, CDialog)
//{{AFX_MSG_MAP(CHWDiagsDlg)
ON_MESSAGE(MY_WM_MESSAGE_SELFTESTS, OnMyMessageSelfTests)
ON_MESSAGE(MY_WM_MESSAGE_ICAM2_WARMUP, OnMyMessageIcam2Warmup)
ON_MESSAGE(MY_WM_MESSAGE_ICAM2_IMAGENOISETESTS,
OnMyMessageIcam2ImageNoiseTest)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_WM_CLOSE()
ON_BN_CLICKED(IDC_exit, Onexit)
ON_BN_CLICKED(autodetect, Onautodetect)
ON_BN_CLICKED(deviceInfo, OndeviceInfo)
ON_CBN_SELCHANGE(IDC_Loops, OnSelchangeLoops)
ON_BN_CLICKED(IDC_Disconnect, OnDisconnect)
ON_BN_CLICKED(IDC_CancelTesting, OnCancelTesting)
ON_WM_TIMER()
ON_WM_CTLCOLOR()
ON_BN_CLICKED(IDC_TestLog, OnBnClickedTestlog)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

*********************

I very much appreciate the quick responses Gurus!

From: David Wilkinson on 15 Jan 2007 08:41
tomasu(a)gmail.com wrote:

> Text of the ASSERT:
>
> _AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
> { ASSERT(afxCurrentResourceHandle != NULL);
> return afxCurrentResourceHandle; }
>
> *********************
>
> Call Stack:
>
> mfc80d.dll!AfxGetResourceHandle() Line 24 + 0x1e bytes C++
> mfc80d.dll!AfxFindResourceHandle(const char * lpszName=0x00000094,
> const char * lpszType=0x00000005) Line 239 + 0x5 bytes C++
> mfc80d.dll!CPropertyPage::CommonConstruct(const char *
> lpszTemplateName=0x00000094, unsigned int nIDCaption=0) Line 128 + 0xb
> bytes C++
> mfc80d.dll!CPropertyPage::CPropertyPage(unsigned int nIDTemplate=148,
> unsigned int nIDCaption=0, unsigned long dwSize=52) Line 96 C++
> HWDiags.exe!TAB_ICAM2::TAB_ICAM2() Line 29 + 0x53 bytes C++
> HWDiags.exe!`dynamic initializer for 'ICAM2_Dlg''() Line 31 + 0x28
> bytes C++
> msvcr80d.dll!_initterm(void (void)* * pfbegin=0x004a04b0, void
> (void)* * pfend=0x004a05cc) Line 855 C
> HWDiags.exe!__tmainCRTStartup() Line 501 + 0xf bytes C
> HWDiags.exe!WinMainCRTStartup() Line 403 C
> kernel32.dll!7c816fd7()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> kernel32.dll]
>

tomasu:

In your call stack I do not see the call to your derived
WinApp::InitInstance(), but I do see calls to
CPropertyPage::CPropertyPage() and CPropertyPage::CommonConstruct().

Do you have a global CPropertyPage object? If so, why?

David Wilkinson
 |  Next  |  Last
Pages: 1 2 3
Prev: Error writing file: VS2005
Next: deploying mfc-based ActiveX control (VC++ 2005)