C / C++ / MFC

27-Feb-08 7:40

Mark Salsbery wrote:
Hook Uppppppp! Fishing is GREAT today!

hehe check this out[^]

urudakis wrote:
but all i get is a lot a symbols

ROTFLMAO

here's another[^]. Maybe we should ask Chris to start a CPWTFPOTD forum Laugh | :laugh:

Last modified: 14mins after originally posted --

led mike

Mark Salsbery27-Feb-08 9:21

27-Feb-08 9:21

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Vaclav_27-Feb-08 6:34

27-Feb-08 6:34

Thanks for reply.

...long running routine because it's all in one thread....
....
AfxGetMainWnd()->PostMessage(WM_TEST, 1, 1);
AfxGetMainWnd()->PostMessage(WM_TEST_1, 1, 1);
return strText;

This short code does not work either.
Only the first message is actually processed.
So what is MS definition of "message queue"?
It looks like there is no queue at all.
I'll check GetQueueStatus to see if it gets me some more info.

PS > should read ->

led mike27-Feb-08 7:04

27-Feb-08 7:04

It appears you are not properly posting '<' and '>' characters

Vaclav_Sal wrote:
So what is MS definition of "message queue"?

They hide that information in the documentation[^]

Vaclav_Sal wrote:
AfxGetMainWnd()->PostMessage(WM_TEST, 1, 1);
AfxGetMainWnd()->PostMessage(WM_TEST_1, 1, 1);

What is the values of WM_TEST and WM_TEST_1 and how are you trying to receive them?

led mike

Vaclav_27-Feb-08 7:48

27-Feb-08 7:48

Both WM_TEST and WM_TEST_1 are WM_USER defined messages.
For now CMainFrame::PreTranslateMessage(MSG* pMsg)
receives the messages and just does status bar text update plus AfxMessageBox for simple trace debugging.

Snippet here:

....
case WM_TEST: // WM_USER+7
{

m_wndStatusBar.SetPaneText (1, "Status : TEST TEST TEST TEST ", TRUE);
AfxMessageBox("TEST Update status ");

break;
}

case WM_TEST_1: // WM_USER+7
{

m_wndStatusBar.SetPaneText (1, "Status : WM_TEST_1 WM_TEST_1 WM_TEST_1 ", TRUE);
AfxMessageBox("WM_TEST_1 Update status ");
break;
}
...

I do not fully understand how to implement the retrun value of PreTranslateMessage.Either way - replacing the case break with return true or false did not make any difference.
I am still looking into GetQueueStatus and see if I can use it in
PreTranslateMessage.

led mike27-Feb-08 8:41

SOLVED Cascading PostMessage

27-Feb-08 8:41

Vaclav_Sal wrote:
For now CMainFrame::PreTranslateMessage(MSG* pMsg)

Well assuming you actually have WM_TEST AND WM_TEST_1 defined with different values rather than the same WM_USER + 7 as commented in your code, if you change AfxMessageBox to TRACE statements you will see you receive both messages. If you give control of the message queue to the message box by popping it up the second one gets eaten before your code starts executing again.

led mike

Vaclav_27-Feb-08 9:19

27-Feb-08 9:19

As you suggested - removing the message box works as advertised!
Thanks for your help, appeciate it.
Vaclav

Mark Salsbery27-Feb-08 8:55

27-Feb-08 8:55

First, you should be using WM_APP, not WM_USER.

Second, are both WM_TEST and WM_TEST_1 equal to WM_USER+7 as indicated by your comments?

Third, why use PreTranslateMessage() to catch the messages? You can't handle the message
in the standard MFC way?
If you must use PreTranslateMessage(), then return non-zero to discontinue any further processing of
the message. Return zero to let the message be dispatched/processed normally.

I did this in my little MFC test app, where the app's main window is a modal dialog...

// Added to CMFCTesterDlg class declaration (h file)

    afx_msg LRESULT OnTest(WPARAM wp, LPARAM lp);
    afx_msg LRESULT OnTest1(WPARAM wp, LPARAM lp);


// Added to CMFCTesterDlg class implementation (cpp file)

#define WM_TEST      (WM_APP+7)
#define WM_TEST_1    (WM_APP+8)

BEGIN_MESSAGE_MAP(CMFCTesterDlg, CMyDialog)
    ON_MESSAGE(WM_TEST,&CMFCTesterDlg::OnTest)
    ON_MESSAGE(WM_TEST_1,&CMFCTesterDlg::OnTest1)
END_MESSAGE_MAP()

void CMFCTesterDlg::OnOK()
{
    AfxGetMainWnd()-> PostMessage(WM_TEST, 1, 1);
    AfxGetMainWnd()-> PostMessage(WM_TEST_1, 1, 1);
}


LRESULT CMFCTesterDlg::OnTest(WPARAM wp, LPARAM lp)
{
    AfxMessageBox(_T("WM_TEST Update status "));
    return 0;
}


LRESULT CMFCTesterDlg::OnTest1(WPARAM wp, LPARAM lp)
{
    AfxMessageBox(_T("WM_TEST_1 Update status "));
    return 0;
}

Both messages are received (interestingly in reverse order they were posted).

What are you doing differently?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Vaclav_27-Feb-08 9:26

27-Feb-08 9:26

First, you should be using WM_APP, not WM_USER.
Did that with same results.

Second, are both WM_TEST and WM_TEST_1 equal to WM_USER+7 as indicated by your comments?
No they are not same.

Third, why use PreTranslateMessage() to catch the messages? You can't handle the message
in the standard MFC way?
I could.

If you must use PreTranslateMessage(), then return non-zero to discontinue any further processing of
the message. Return zero to let the message be dispatched/processed normally.
Did that with same resluts.

Mark Salsbery27-Feb-08 9:30

27-Feb-08 9:30

Fair enough Smile | :)

Interesting that using normal MFC message processing like in my example code works fine -
the message doesn't get eaten, although only one modal message window can appear at a time...

Cheers,
Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike27-Feb-08 9:45

27-Feb-08 9:45

Mark Salsbery wrote:
If you must use PreTranslateMessage(), then return non-zero to discontinue any further processing of
the message. Return zero to let the message be dispatched/processed normally.

I agree but it has no effect on the second message getting processed in the message loop of the MessageBox right?

led mike

Mark Salsbery27-Feb-08 10:24

27-Feb-08 10:24

I believe so. I would expect the modal message loop of the first dialog to eat the message
that's still in the queue.

That's what happens in my sample code - it appears the messages get processed in revere order, but actually
the modal processing of the first dialog makes the second queued message get processed, popping up the second
message box first. Once that's dismissed, the first dialog continues processing.

I think that should have happened in the OP's code too...something was wrong somewhere else IMO.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike27-Feb-08 10:45

27-Feb-08 10:45

Mark Salsbery wrote:
I think that should have happened in the OP's code too...something was wrong somewhere else IMO.

I don't think so, I just reproduced it in an SDI app. Returning 1 or 0 has no effect on the behavior, the MessageBox appears to process the message in either case which makes sense since my return does not happen until after the MessageBox is destroyed.

I think in your case you are not using PreTranslate and so MFC CommandTarget or something is getting hold of it then who knows what is happening.

led mike

Mark Salsbery27-Feb-08 10:51

27-Feb-08 10:51

Interesting... I'm also already in a modal loop in my main window - I wonder how different that makes things.

Are you using an app class PreTranslateMessage() override or main window class override?

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike27-Feb-08 10:58

27-Feb-08 10:58

Mark Salsbery wrote:
Are you using an app class PreTranslateMessage() override or main window class override?

My CFrameWnd derivation

led mike

Mark Salsbery27-Feb-08 11:31

27-Feb-08 11:31

hmm....

I can't figure out where that second message goes...

It never gets routed through PreTranslateMessage, but gets dispatched through the message map of the
destination window just fine.

Moral: PreTranslateMessage() is a bad place to do message boxes from LOL

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike27-Feb-08 11:33

27-Feb-08 11:33

I would guess the answer is the code of the main MFC message loop Wink | ;)

led mike

Mark Salsbery27-Feb-08 11:38

27-Feb-08 11:38

hehe yeah I just can't find it. Thankfully I'm unwilling to try any further because it's never
going to be an issue that affects ME, and I'm selfish like that LOL

Cheers man! Beer | [beer]

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

David Crow28-Feb-08 2:32

David Crow

28-Feb-08 2:32

Mark Salsbery wrote:
Moral: PreTranslateMessage() is a bad place to do message boxes from

That's a given. I wonder if the issue has anything to do with the message box being a modeless dialog in disguise.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Mark Salsbery28-Feb-08 8:15

28-Feb-08 8:15

I couldn't get that far to find out. I was unable to step into the source code for
the innards of the AfxMessageBox on VS 2008 (the trail ended at a call to an imported library
function which wasn't debuggable), so I couldn't even see what "modal" loop it was using.

That's why I was unable to find where that second message gets eaten.

Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Vaclav_4-Mar-08 7:59

GDI or GDI+ from worker thread safely?

4-Mar-08 7:59

Mark and Mike.
FYI check
Microsoft Systems Journal June 1996

There is some info on modal dialogs message behavior which may explain things.
PS I am still working on my solution to this dilema. Making some progress.
Vaclav

Greg Ellis27-Feb-08 5:04

Greg Ellis

27-Feb-08 5:04

Hey guys,

I have an application where I need to keep the UI responsive while background tasks are running.

I currently have worker thread that does a PostMessage to a handler that does my GDI drawing, but the problem is that if too many things are happening the message pump gets held up and therefor my UI drawing is not smooth at times. If there was some way I could just do my GDI or GDI+ drawing directly from the worker thread I know that would solve my problems and my UI would be responsive.

Is there anyway I can do my drawing directly from a woker thread safely using either GDI, GDI+, or even DirectX? any way at all?

Re: GDI or GDI+ from worker thread safely?

led mike27-Feb-08 5:25

Re: GDI or GDI+ from worker thread safely? [modified]

27-Feb-08 5:25

You can do your drawing into off screen buffers in the worker thread then signal the main thread to update the display and all it has to do is draw the buffer(s) making it much faster. But you haven't indicated what you are actually doing so I don't know if that is helpful.

led mike

Greg Ellis27-Feb-08 5:28

Greg Ellis

27-Feb-08 5:28

Oh cool, so I can actually safely use GDI calls to draw on an offscreen device context from directly within the thread so long as I dont do anything with an actual windows control? Then just update the actual windows control from the main thread?

modified on Wednesday, February 27, 2008 11:41 AM

Re: GDI or GDI+ from worker thread safely?

Mark Salsbery27-Feb-08 5:43