From: Joseph M. Newcomer on
I know you pointed out that it was line 2688. But in WHAT FILE? This is clearly not part
of MFC, and therefore, since you give the code completely out of context, it is
questionable what it is doing or even why it exists.

If it is part of your code, you have said nothing that would suggest where it is or why it
exists.
joe

On Mon, 21 Sep 2009 06:35:52 -0700 (PDT), neilsolent <n(a)solenttechnology.co.uk> wrote:

>
>> Sounds about right. �Where, exactly is this code? �I cannot find these lines anywhere in
>> the MFC runtime. �I specifically looked in the VS98 MFC source directory and could not
>> find them.
>
>Joseph,
>
>The code was in the first post, line 2688 was clearly marked:
>
> MSG msg;
> while (GetMessage(&msg, NULL, 0, 0) == TRUE)
> {
> LOGWARN "Received msg: [message=%u, hwnd=%d,
>wParam=%u, lParam=%u,
>x=%u, y=%u]",
> msg.message, msg.hwnd, msg.wParam,
>msg.lParam, msg.pt.x,
>msg.pt.y);
> ..
> ..
>
>
> TranslateMessage(&msg);
> DispatchMessage(&msg); // <- Line
>2688
> }
>
>
>.. hence the last call from my code is DispatchMessage() - after that
>the code is in Microsoft's libraries.
>
>> Note that if this is your code, then your code is erroneous, because it should not have
>> anything like this in it.
>
>Shouldn't have anything like what in it?
>Are you saying I shouldn't use DispatchMessage()?
>Why not, and how else do the MFC callbacks get processed ?
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
I'm wondering if you wanted to run an async socket in a separate thread, and this is your
code for doing so. If so, it is highly suspect code. The correct way to run a socket in
a secondary thread is to create a UI thread to handle it; in general, you can have high
confidence that if you are writing a message pump in MFC, you are doing something very
wrong.
joe

On Mon, 21 Sep 2009 10:25:01 -0400, Joseph M. Newcomer <newcomer(a)flounder.com> wrote:

>I know you pointed out that it was line 2688. But in WHAT FILE? This is clearly not part
>of MFC, and therefore, since you give the code completely out of context, it is
>questionable what it is doing or even why it exists.
>
>If it is part of your code, you have said nothing that would suggest where it is or why it
>exists.
> joe
>
>On Mon, 21 Sep 2009 06:35:52 -0700 (PDT), neilsolent <n(a)solenttechnology.co.uk> wrote:
>
>>
>>> Sounds about right. �Where, exactly is this code? �I cannot find these lines anywhere in
>>> the MFC runtime. �I specifically looked in the VS98 MFC source directory and could not
>>> find them.
>>
>>Joseph,
>>
>>The code was in the first post, line 2688 was clearly marked:
>>
>> MSG msg;
>> while (GetMessage(&msg, NULL, 0, 0) == TRUE)
>> {
>> LOGWARN "Received msg: [message=%u, hwnd=%d,
>>wParam=%u, lParam=%u,
>>x=%u, y=%u]",
>> msg.message, msg.hwnd, msg.wParam,
>>msg.lParam, msg.pt.x,
>>msg.pt.y);
>> ..
>> ..
>>
>>
>> TranslateMessage(&msg);
>> DispatchMessage(&msg); // <- Line
>>2688
>> }
>>
>>
>>.. hence the last call from my code is DispatchMessage() - after that
>>the code is in Microsoft's libraries.
>>
>>> Note that if this is your code, then your code is erroneous, because it should not have
>>> anything like this in it.
>>
>>Shouldn't have anything like what in it?
>>Are you saying I shouldn't use DispatchMessage()?
>>Why not, and how else do the MFC callbacks get processed ?
>Joseph M. Newcomer [MVP]
>email: newcomer(a)flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: neilsolent on
On 21 Sep, 15:25, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> I know you pointed out that it was line 2688.  But in WHAT FILE?

The name of the file is of no importance. The stack trace refers to a
line 2688. Hence I pointed to the line 2688 of my code.

> This is clearly not part
> of MFC, and therefore, since you give the code completely out of context, it is
> questionable what it is doing or even why it exists.  
> If it is part of your code, you have said nothing that would suggest where it is or why it
> exists.

The context is as stated in the first post

From: neilsolent on

> I'm wondering if you wanted to run an async socket in a separate thread, and this is your
> code for doing so.  If so, it is highly suspect code.  The correct way to run a socket in
> a secondary thread is to create a UI thread to handle it; in general, you can have high
> confidence that if you are writing a message pump in MFC, you are doing something very
> wrong.
>                                 joe

Yes I am running an async socket in a "separate" thread. Why is it
highly suspect code?
This code now works fine. I think it is clear what the problem was and
how I solved it from my posts.
My app does not have a user interface.
I don't mind people making negative remarks - but please give a proper
explanation of why you think what I am doing won't work.
From: Stephen Myers on
neilsolent wrote:
>> I'm wondering if you wanted to run an async socket in a separate thread, and this is your
>> code for doing so. If so, it is highly suspect code. The correct way to run a socket in
>> a secondary thread is to create a UI thread to handle it; in general, you can have high
>> confidence that if you are writing a message pump in MFC, you are doing something very
>> wrong.
>> joe
>
> Yes I am running an async socket in a "separate" thread. Why is it
> highly suspect code?
> This code now works fine. I think it is clear what the problem was and
> how I solved it from my posts.
> My app does not have a user interface.
> I don't mind people making negative remarks - but please give a proper
> explanation of why you think what I am doing won't work.

The UI thread design supplies the message pump for you. The name is
unfortunate. If you replace the name UI Thread with Thread with message
pump it helps.

The biggest problem with the code is that you seem to be doing it the
hard way. I would use the OnClose() override to delete the socket. If
you need to close the socket at other times, Close() is easy. Using a
UI thread leaves you with a small amount of code in InitInstance and the
a few message handlers.

Steve
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Knit picking
Next: No source on specified on that location