CWnd::PostMessage in dialog based app

Hi,
I'm writing a dialog based app using MFC (VC5). The main window is a Wizard (CPropertySheet). One page contains a modified CStatic control. This control sends notifications to it's parent window using GetParent()->PostMessage(...). On another page, I start a worker thread, which is also sending messages to the dialog using ::PostMessage(...) with the correct window handle.
If I'm creating a debug version with standard settings, everything works fine. But when I run the release version, I can exactly do ONE PostMessage. If it comes to the second one, the program crashes with an 0xC0000005: Access Violation in MFC42.DLL. The debugger stops in AFXCRIT.CPP, line 100. The call stack is CWnd::~CWnd -> AfxLockGlobals, if this information is helpfull...
What could be the cause for this strange behaviour?
LVL 1
chumpAsked:
Who is Participating?
 
lucidityConnect With a Mentor Commented:
use CWnd:SendMessage() it will hold the thread until the message gets processed, ih the message is not allowed to be processed then strange things may happen
---------------
1. Check if the handler function has the correct parameters passed and returns the correct type. This is not checked by the compiler and it works fine in debug version, but doesn't in the release version. I had the problem that my handler function had only one input parameter while it had to have two input parameters.

Next
I am not sure how U have modified the CStatic control.. But, this is what the documentation for CStatic says...

"A static control normally takes no input and provides no output; however, it can notify its parent of mouse clicks if it's created with SS_NOTIFY style."

1. So U may want to check if U have created the static control with the style

2. Posting a Message from another control but calls the same handler function and check if it is still giving a problem..

3. Since, it is happening after exactly after one PostMessage and occurs just after the SendMessage, I think it might be in the code that is handling the message, because, PostMessage returns as soon as the message is posted and does not wait for the message to be processed, but SendMessage waits for the message to get processed and so it may be in the handler also.

0
 
bfwizardCommented:
This is sort of an answer of why I believe this is happening in the release version and not the debug version.  In the debug version MFC allocates memory in such away that it sets up guard bytes that surround allocated memory...and sometimes this can fend off an access violations in the debug version and why they are caught in the release version.

2 options to help find errors:



The first option(if you are doing a lot of allocating/deallocating) is (if you know about where the error is), while you are in the debug version, to call the AfxCheckMemory function yourself.

ASSERT(AfxCheckMemory());
   
///the code where you think the error is occuring

ASSERT(AfxCheckMemory());

if the first ASSERT clears and the second one fails you know that the error is between this section of code.


Another option is if you put the statement in the application InitInstance function:

afxMemDF |= checkAlwaysMemDF;

it forces a call to AfxCheckMemory while in debug mode everytime you allocate and deallocate memory (every time new and delete are called).  If something goes wrong you wont get an assertion, but you will get a message in the debug window (while in debug mode): Damage Occurred! Block=xxxxx.  from there you should be able to trace down through in your code where it occurred.  But....if you have many things allocating/deallocating memory it might slow things down considerably.
0
 
chumpAuthor Commented:
Sorry, your answer didn't help me.

> if you are doing a lot of allocating/deallocating

I'm not. I commented all the code inside the message handling and the message creating function (except PostMessage of course), still the error occurs.

> if you know about where the error is

I don't know. I put OutputDebugString("...") as the only statement in the function that handles the message, the string gets printed.

>afxMemDF |= checkAlwaysMemDF;

This does only work in debug mode - so the error doesn't occur.

Btw, I replaced the PostMessage calls with calls to SendMessage. In that case the same crash occurs, but already after the first call to SendMessage.
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
chumpAuthor Commented:
Sorry, your answer didn't help me.

> if you are doing a lot of allocating/deallocating

I'm not. I commented all the code inside the message handling and the message creating function (except PostMessage of course), still the error occurs.

> if you know about where the error is

I don't know. I put OutputDebugString("...") as the only statement in the function that handles the message, the string gets printed.

>afxMemDF |= checkAlwaysMemDF;

This does only work in debug mode - so the error doesn't occur.

Btw, I replaced the PostMessage calls with calls to SendMessage. In that case the same crash occurs, but already after the first call to SendMessage.
0
 
footlooseCommented:
Check the return value from GetParent(). Maybe it is returning NULL.
I hope you are aware of the standard precautions when using window handles between threads. Refer to MFC on-line help on multi-threading for more info.
0
 
chumpAuthor Commented:
Actually, the code is:
if ( GetParent( ) )
   GetParent( )->PostMessage( WM_MYMESSAGE );
And, the message handling function gets called, the crash happens somewhere later.

Linking with the single threaded MFC Dll makes not difference, so in the first case, there's no multithreading.

0
 
bfwizardCommented:
I guess my point was that you were addressing something that is not allocated or was already deallocated...this doesn't always cause access violations in the debug version.  If you already know exactly where in the code this is happening then you are mostly there.
0
 
chumpAuthor Commented:
Have to correct myself. VC didn't build a single threaded version.

But, I did message passing the same way in an MDI app (between a thread and a CView) and had no problems there...
0
 
t004024Commented:
1. Check if the handler function has the correct parameters passed and returns the correct type. This is not checked by the compiler and it works fine in debug version, but doesn't in the release version. I had the problem that my handler function had only one input parameter while it had to have two input parameters.

Next
I am not sure how U have modified the CStatic control.. But, this is what the documentation for CStatic says...

"A static control normally takes no input and provides no output; however, it can notify its parent of mouse clicks if it's created with SS_NOTIFY style."

1. So U may want to check if U have created the static control with the style

2. Posting a Message from another control but calls the same handler function and check if it is still giving a problem..

3. Since, it is happening after exactly after one PostMessage and occurs just after the SendMessage, I think it might be in the code that is handling the message, because, PostMessage returns as soon as the message is posted and does not wait for the message to be processed, but SendMessage waits for the message to get processed and so it may be in the handler also.
0
 
Andy_KeysCommented:
AFX_MANAGE_STATE(AfxGetStaticModuleState( )) at the start of the FN before you call the PostMessage ie put it as the first line of code and see if that helps.

0
 
chumpAuthor Commented:
Sorry, Andy, doesn't help.
0
 
chumpAuthor Commented:
t004024, I tried posting the message from another control.
I put the PostMessage call in the OnClick handler of a button on the same page. Now I can click this button _two_ times, clicking it for the _third_ time causes the crash.
The handler for the function doesn't execute any code (I commented it out).
0
 
chumpAuthor Commented:
t004024, you're right. I was taking the wrong return type.
Thanks very much. Write an answer, and you'll get the points.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.