Debug assertion failure in mfc app

After I get the error, click on Retry, and get a message the my app has triggered a breakpoint ... the breakpoint is on the line in the first message, line 329.

I neglected to say this, but this project was originally built in VS2003 and then VS2008 converted it.  Sorry if this might have some impact.

So try to open the dialog form in the resource editor, maybe, even add a button/static text, and fully rebuild the solution.

What is the code in the line the error appears on - different versions of MFC may well not have the same code at that line.

in vs2003 the assertion failure happens on line 330: in vs2008 the assertion failure happens on line 329 ... both in wincore.cpp.  It is the same code which is:
BOOL CWnd::Attach(HWND hWndNew)
{
      ASSERT(m_hWnd == NULL);     // only attach once, detach on destroy
      ***** the above line is where the assertion fails! ***************

                ASSERT(FromHandlePermanent(hWndNew) == NULL);
            // must not already be in permanent map

adding items to the dialog and building the project from scratch (clean then build) doesn't change anything.

It is in Attach. What are you attaching?
Probably, there are differences between the MFC structures and classes in 2003 and 2005.
You've tried to build the project from scratch in VS2003 and it didn't help.
Precompiled headers - what's wrong with it? MFC applications like it.

I didn't say anything was wrong with precompiled headers ... I simply said I am not using precompiled headers.  With or without them doesn't help my situation with this error.  

I am not attaching anything specific that I know of.  Everything is MS and I'm not using any 3rd party tools, just what's in the studio.  And it is all fine in release mode.  I'm a novice so I'm not even sure what questions to ask at this point, so don't think I'm being obscure deliberately;  I just don't know where else to look.

OK, I found the problem. I was subclassing some button controls to add graphics to them.  Once I commented them out of the dialog init routine, the error went away.

So my last post was wrong.  I am using the sxbutton.cpp code I found on the web, I believe at CodeGuru.com, to add some graphics to my buttons.

Thanks to all who responded and sorry for the incorrect post.

I think this answer ID:25238038 helped to find the problem.

>>Once I commented them out of the dialog init routine, the error went away.

I think you will find one (or more) was being subclassed more than once.  Or you added a member variable to one (or more) via the wizard.

All you need to do is just comment out the line where the ID is being used a second time.


ps.  That is why I wanted to know what the code was that asserted - it helps the experts here to find out what was wrong and give a useful suggestion.

Here's my response:

The last two comments, 25248079 and 25248182, are totally wrong for this question as they didn't read my closing comment.  The error had nothing to do with those suggestions, in fact, not even close.

While comment 25238038 was interesting, as my closing comment states, I wasn't "attaching" anything, I was subclassing a couple of buttons on the dialog.  The other mention of pre-compiled headers also has nothing to do with it.  

I appreciate the responses and am always generous in awarding points to the respondents.  However, in this case I "stumbled" on the answer myself.  I will leave it to the moderator to award the points the best way he or she sees fair without argument.

>>Here's my response:
The last two comments, 25248079 and 25248182, are totally wrong for this question as they didn't read my closing comment.


Interesting.  My comment (25248079) adresses this sort of error found in subclassing (as stated by the asker in his closing comment).  If a control is subclassed a second time then this ASSERT will be thrown.  A blanket removal of all the subclassing  code (as the asker states he does) will cure the error, but is in fact a complete overkill.  All that is required is to not subclass that control a second time and the functionality (graphics) will still be available.

dhenderson12: I'm not sure you understatood what was the reason for the assert. SetWindowLongPtr in Win API does not contain any ASSERT. Probably you used SubclassWindow from MFC and the fist line there is the check:
if (!Attach(hWnd))
return FALSE;
So tell us that we were not right.
So if another programmer will look in EE for the same problem, he will find this thread and will think what? Subclassing fails when it is used for the adding some graphic?

No, I didn't use subclass window.  Here is the offending code:

      m_UserOptions.SubclassDlgItem( IDC_BUTTON_USEROPTIONS, this );
      m_UserOptions.SetIcon( IDI_ICON_PICTURE1, 40, 40);
      m_UserOptions.SetImagePos( CPoint( SXBUTTON_CENTER, 6));
      m_UserOptions.SetTextPos( CPoint( SXBUTTON_CENTER, 42));
      m_UserOptions.EnableWindow(0);

When this is commented out, the assertion failure goes away.

dhenderson12, please now read your original question - you didn't have any idea what's going on.
Now say that you found and fixed the problem yourself.

I have a class that enables me to add graphics to a button control;  Why I want the graphics is not part of the discussion or your concern.

I have a standard button control (only one).  To use the graphics on the button I need to subclass the button (the instructions of the sfxbutton class).  This is only done once, not a bunch of times as your made-up example.  I have only one button and one dialog (do you think I'm making this up?).

As far as what others will dicern from the problem I was having and the solution I found for it, that will have to be judged by whether or not they actually READ the solution I posted as to what was happening in my code, not by problems being fabricated to allow the answer to fit the fabrication.

>>This is only done once

That is NOT possible - if it was the case then you would not get an ASSERT at the line of code you indicate.

ok, guys.  you caught me.  I'm lying.  I made the whole thing up.  I'll split the points just because you answered the email.  just let me know what answers you want me to accept as an answer, the ones that don't actually answer a question or the one that give the bogus example code that makes the question fit the answer.

ID:25220777
:)

I knew that.

>>ok, guys.  you caught me.  I'm lying.

I hope not and actually think you are just p***d off.

I think you have been telling the truth as you know it BUT that it was in fact incorrect due to lack of understanding of MFC and Windows operate.
I think you have not been prepared to accept that other might have been giving good information and advice and rather than saying to yourself 'erm, maybe they know something I don't, I'd better check' you have been just assuming you know better.

If I am correct in my thoughts then a final piece of advice - consider a career change, you aren't likely to hack it as a programmer with such an attitude.