MFC SendMessage does not return

[baillie]

Hello all,

I'm having a problem returning from a SendMessage command. Here's the story:

I'm click on a ListBoxExBuddy which is a class that sets up and handles clicking on insert, delete, up and down buttons on a ListBox (Copyright (C) Stefano Passiglia, December 1999).

We have been using this class for a long time and I'm sure that it is not the problem. (famous last words)

Anyhow, I click on the add button. This click gets picked up by the listboxexbuddy and sends a message that is received by our CClassification class. That class then creates and displays a new dialog.

This dialog contains a couple of edit boxes that when you click on them, display yet another dialog (CMetadataLangString). This dialog now has another ListBoxExBuddy on it. I click add on that guy and the exact same message is sent that was sent earlier on. It is received by a function in this CMetadataLangString object (dialog).

Now, when that function attempts to return (from the message call), I get an error. The message sent both times is as follows:

LRESULT retVal = GetParent()->SendMessage( UWM_LBBINSERTSTRINGPRECHECK, m_pListBoxEx->GetCurSel(), (DWORD)m_pListBoxEx );

The error message that I get is:
"The instruction at memLocation referenced memory at memLocation. The memory could not be read."

If I eliminate the receiving of the second message, there's no problem. The message is sent a second time, it is not received anywhere and all goes fine. The two SendMessage commands unwind from the stack with no problem.

As soon as the second sending of the message is received, then the return from that second message never finishes. Even if the function that received the second message only consists of: return 1;

The error only occurs in release mode. Debug gets no error and the results are all correct and as expected.

It looks to me like the message is being sent fine, but can not return, as if there is a conflict with the unwinding of the stack after these two same SendMessage commands. I put a MessageBox directly before the SendMessage and directly after the SendMessage. I see two of the before messages, but none of the after messages. I also put a MessageBox immediately before the receiver of the second message does it's return. I see that message displayed and then the error occurs without ever getting to the message that directly follows the SendMessage.

I'm pretty well stumped on this one. Any help will be greatly appreciated.

Thanks.

 

[PerFnurt]

>The error only occurs in release mode. Debug gets no error

Smells like access of unitialized memory. Every time Ive hade problem in release thats not reproducable in debug its been memory related. Are you sure you dont override buffers or someting?


/Per
[sub]
if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;
[/sub]

 

[dlldelhi]

Yeah check the memory been initialized of variables...
In 2-Phase compiler which is of C, Debug works because it attachs most of the libraries or system reources but in release they are not attached so release gives you a true picture as how the app aould work. In MFC most of the libs are attached in debug...
Anyway I mostly worked on SDK only a bit on MFC app...
I think problem might have been with inproper initialization
Recheck them

 

[baillie]

Thanks for the suggestions/tips. It was an initialization thing. Here's what happened.

The message being sent had two parameters. One of the functions receiving the message used those parameters. The other function receiving the message had no use for the parameters so I figured &quot;why waste resources declaring the funtion with parameters&quot;. I actually didn't think that it would compile, let alone execute. Well, it did in debug.

By the time I got around to testing it in release mode, I had forgotten about my great discovery in debug.

Anyway, here is an explanation of what seems to be happening from a colleague of mine.

Quote:
Ah, yes. The other thing debug does (&quot;now he tells me&quot is &quot;pad&quot;
function calls on the stack so there won't be a stack problem if, say, you
send a function parameters that it isn't expecting. Release doesn't do
that, of course, and goes nuke if it happens.
End Quote:

Again, thanks for your time.