Debug Assertion Error in VC++6

downhiller80

Platinum Member
Apr 13, 2000
2,353
0
0
OK very VERY basic programming here. I'm trying to remember the basics! Been too long . . .


void CMyPicDlg::eek:nSize(UINT nType, int cx, int cy)
{
CDialog::eek:nSize(nType, cx, cy);

////// MY CODE

m_bmp.SetWindowPos(NULL,0,0,cx,cy,NULL);

////// MY CODE
}

m_bmp is variable for a Tegosoft BMP ActiveX object.

Why when I run this do I get a Debug assertion error in line 290 of winocc.cpp?
Hell what IS a debug assertion error :)

Cheers

Seb
 

br0wn

Senior member
Jun 22, 2000
572
0
0
not sure exactly what is in your code...you have
smilies in there :)

Assertion errors are checkpoints set by
the programmer to make sure that variables
(or parameters to function) contain CORRECT
range of values.

// CODE START

// if I want to make sure x contains value greater than 0,
// before using x, I will assert the following line :
ASSERT(x > 0);

// CODE END

Thus if x is negative number, the compiler will complain
about assertion errors at that line (it makes the program
EASIER and FASTER to debug)

Just check line 290 of winocc.cpp, and see which
conditions that your code doesn't satify :p
 

downhiller80

Platinum Member
Apr 13, 2000
2,353
0
0
Well you can work out my code because you know :eek: is ": o" with no space (actually ": O").

The line in winocc.cpp is:

ASSERT:):IsWindow(m_hWnd));

What confuses me is the same line of code (m_bmp.SetWindowPos(NULL,0,0,cx,cy,NULL);

) causing the trouble works fine in a different section of the program.

This instance resizes the bmp object as the window is resized.

Seb
 

downhiller80

Platinum Member
Apr 13, 2000
2,353
0
0
Feck it. I found an easier solution. Just put VC++ onto release instead of debug. Fine by me :)

Seb
 

HigherGround

Golden Member
Jan 9, 2000
1,827
0
0


<< Thus if x is negative number, the compiler will complain
about assertion errors at that line (it makes the program
EASIER and FASTER to debug)
>>



thats not quite true, assertion macro is called during runtime, not during compile or link time. When not in debug mode the prepocessor defines a NDEBUG (or eqiuvalent depending or the system) identifier and the macro is redefined to do nothing (void)0. That's why sebfrost's errors went away when switching to release mode. I would go back to debug and try to identify the problem. I immediatly see that you are passing NULL,0,0,int,int,NULL to the SetWindowPos(HWND hWndInsertAfter,int x,int y,int cx,int cy,UINT nFlags), so you are passing NULL as the handle to the hWndInsertAfter parameter (this causes the assert(...) to abort, because NULL is not a valid window handle)...to fix the problem, pass a valid value to the handle, which can can be (HWND_BOTTOM, HWND_NOTOPMOST, HWND_TOP, HWND_TOPMOST), so the call looking like this m_bmp.SetWindowPos(HWND_TOP,0,0,cx,cy,NULL); would reposition the window and place it at the top of the stacking order ( actually this is also not 100% correct, because we are still passing NULL in place of the nFlags) ... so, if you could care less about stacking order you can pass SWP_NOZORDER in place of the uFlags parameter. The call would look like this m_bmp.SetWindowPos(HWND_TOP,0,0,cx,cy,SWP_NOZORDER);. (The position flags are defined in Winuser.h definition file). That should hepefully do it. LMK if it doesn't, i've been away from Win32/MFC programming for a while so i might not be 100% on target with my explanation.
 

br0wn

Senior member
Jun 22, 2000
572
0
0
yup, I stand corrected (thanks to HigherGround),
assertion macros are being checked during runtime
(I thought I said it that way :p, but it might be too
ambigious from my previous reply).

In my example above, if x is INPUT from USER,
there is NO WAY compiler will know
if x is greater than 0 AT COMPILE TIME.

For sebfrost, if this is just a fun program
or nothing critical nor productive, I'd agree with
you ignoring the error(although the error will still occur
once you reach that part of the code when you run the program).
Otherwise, I'd suggest you to fix the errors, since this error
will affect other part of your code and can be troublesome
to debug later (thus this is why, programmer
put an assertion line there :p)
 

downhiller80

Platinum Member
Apr 13, 2000
2,353
0
0
Someone's told me that it may come from my computer using &quot;English (British)&quot; and my compiler using &quot;English (US)&quot;.

I'll try changing these to match and see if that sorts it.

Seb