Problem with Work Threads and MFC MDI App, debug vs release

Hi,

I have an MDI App, which was generated using the Visual Studio V6.0 Wizard.
I create a doc/view template and in the doc I create a 'simple' worker thread. When this thread has done some processing, it does a PostMessage to the main UI thread/view.
I use CCriticalSection around a buffer which is shared between the 2 threads.

Under both debug and release mode this works fine and the view does some UI updating from the work thread. However in release mode, if the main app gets any other windows message, eg app losses focus. It crashes. Under debug this is fine.
If I remove the PostMessage call then no crash. If I remove the code inside the handler to the PostMessage, then still crash, dispite the handler getting the message.

Does anyone have any suggestions as to what maybe wrong?

Thanks,

Ling
linginlondonAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AlexFMCommented:
Please show your code: starting the worker thread, worker thread code and handling the message.
You can also try to solve the problem debugging the Release configuration as described here:

http://www.codeguru.com/debug/release_ver.shtml
0
linginlondonAuthor Commented:
Here is some code snippets:

// create the log view thread object      
      CWinThread* pWinThread = AfxBeginThread(StartTail, reinterpret_cast<LPVOID>(this),
            THREAD_PRIORITY_NORMAL, 0, 0, NULL);

// thread code
UINT CLogDoc::StartTail(LPVOID pParam)
{

// read in data ...
..
CWnd* pWnd = (CWnd *)CWnd::FromHandle(pParam->m_pLogViewHwnd);
PostMessage(pParam, WM_USER+1000, (WPARAM)0, (LPARAM)0);
Sleep(0);
}

// in message map
ON_MESSAGE(WM_USER+1000, OnLogItemReady)
// handler code
void CEditLogView::OnLogItemReady()
{

}


0
ZoppoCommented:
Hi linginlondon,

IMO problem is that your message handler function is defined wrong.
Functions which should be used with ON_MESSAGE macro must be
declared as
afx_msg LRESULT memberFxn(WPARAM, LPARAM);
You're function is declared to return 'void' instead of 'LRESULT'.

Unfortunateley I still don't know how MFC manages to work fine with
this in DEBUG mode but I know it's a common problem (coz the same
happened to me some time ago and I needed some days to figure it out).

Hope that helps,

ZOPPO
0
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

ZoppoCommented:
Sorry, I forgot to mention that you function should even
have two paramters WPARAM and LPARAM ...

Here's a link about this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_user.2d.defined_handlers.asp

ZOPPO
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AndyAinscowFreelance programmer / ConsultantCommented:
It may be better to use the SDK PostMessage fn
instead of
UINT CLogDoc::StartTail(LPVOID pParam)
{

// read in data ...
..
CWnd* pWnd = (CWnd *)CWnd::FromHandle(pParam->m_pLogViewHwnd);
PostMessage(pParam, WM_USER+1000, (WPARAM)0, (LPARAM)0);
Sleep(0);
}

use
UINT CLogDoc::StartTail(LPVOID pParam)
{

// read in data ...
..
::PostMessage(pParam->m_pLogViewHwnd, pParam, WM_USER+1000, (WPARAM)0, (LPARAM)0);
Sleep(0);
}


Also why do you have a Sleep(0); after the postmessage?  Do you want your app to do something before the thread continues?  If so use SendMessage instead of PostMessage as that wont return until the recipient finishes the processing the message.
0
linginlondonAuthor Commented:
Hi Zoppo,

Thanks for you advice, that did the trick. I've just spent the last 2days looking at all the threading code, and it was just a plain error with the function handler definition! Grrr...teach me for using cut and paste coding!

Ling
0
SteHCommented:
Have you tried going to WM_APP instead of WM_USER as base for the message? The range WM_USER to WM_APP is used by MS as well and might interfere.

@AndyAinscow
The Sleep (0) allows the other threads to do message processing; For example the one you just sent. If the worker thread is loading the CPU you would see nothing otherwise. All messages would be handled when the worker thread ends. SendMessage might result in a deadlock. Here the worst case would be that the message doesn't get handled immediatly.
0
AndyAinscowFreelance programmer / ConsultantCommented:
Thanks SteH.
Nice trick rather than implementing a message pump.
0
SteHCommented:
A message pump won't work when in a different thread. It is the same as using a message pump in single threaded app.
0
linginlondonAuthor Commented:
Instead of using WM_USER or WM_APP one could use:
UNIT UWM_MY_UNIQUE_MSG = ::RegisterWindowMessage("Some unique string");

SteH is right on the Sleep(0) - this causes the current thread to give up it's remaining processor time and allows other threads to do some work....In my case after posting message, there was no other immediate need for the thread to hold on to the cpu...
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.