From: Joseph M. Newcomer on 21 Sep 2009 10:25 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 21 Sep 2009 13:53 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 21 Sep 2009 14:03 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 21 Sep 2009 14:11 > 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 21 Sep 2009 14:37 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 |