MFC Chatter sample behaves different on NT & 95
Vincent A. Busam -- vbusam@jetstream.com Friday, March 14, 1997 Environment: Visual C++ 4.2b, Windows NT 4.0, Windows 95. I am having a problem using CSocket and the problem can be seen using the chatter sample program. While this may not be a MFC problem, my program is in MFC and I would like to find a way around the problem, hopefully with CSocket settings. (I've checked the MSDN and VC++ CDs and MS's Knowledge Base on the Web and either the answer isn't there or I haven't found the right search keys.) I can see the problem by starting chatter.exe from the VC++ 4.2 CD (\msdev\samples\mfc\advanced\chatter). In the chatter setup box I enter my handle and the address of a computer on the local LAN (which is up but not running charsvr). Under NT 4.0, I immediately get a "Failed to connect to server" pop-up message box. One of my 95 systems acts the same way. But on my 95 system on my home LAN, what I get is a pop-up dialog asking me do I want to dial my ISP. I assume this this from Dial-Up Networking. (Both my office and home system have Dial-Up Networking installed.) Additionally, with my program which uses CSocket I sometimes (not always) see a long delay (in excess of 10 seconds, but I haven't timed it) during the attempt to open the socket. This seems to be some form of connection timeout. Any ideas how I can eliminate the dial-out pop-up and the connection time delay? I'm moving all of my socket interface to a thread, but I'd prefer to stick with CSocket rather than CAsyncSocket, although this may mean forcing a TerminateThread in case the user closes the application before the socket open terminates. (I have read Mike's book, especially the section about the dangers of TerminateThread.)
Mike Blaszczak -- mikeblas@nwlink.com Tuesday, March 18, 1997 At 09:02 3/14/97 -0800, Vincent A. Busam wrote: >Environment: Visual C++ 4.2b, Windows NT 4.0, Windows 95. >I am having a problem using CSocket and the problem can be seen >using the chatter sample program. While this may not be a MFC >problem, Right: it isn't an MFC problem. >I can see the problem by starting chatter.exe from the VC++ >4.2 CD (\msdev\samples\mfc\advanced\chatter). >In the chatter setup box I enter my handle and the address of a >computer on the local LAN (which is up but not running charsvr). >Under NT 4.0, I immediately get a "Failed to connect to server" >pop-up message box. One of my 95 systems acts the same way. >But on my 95 system on my home LAN, what I get is a pop-up dialog >asking me do I want to dial my ISP. I assume this this from >Dial-Up Networking. (Both my office and home system have Dial-Up >Networking installed.) Yep. The sample is behaving differently by-design. Your two machines are configured differently, and that configuration dictates that the sample behave differently. >Any ideas how I can eliminate the dial-out pop-up and the >connection time delay? 1) Go to the Internet control panel icon. Open it. 2) Select the "Connection" tab 3) Uncheck the "Connect to the Internet as needed box. 4) Click OK Since you've asked that your computer connect to the Internet as needed, any time you end up trying to resolve a name, your computer tries looking around your LAN. If it can't find the name, it tries to connect to the Internet to find the name. >I'm moving all of my socket interface to >a thread, but I'd prefer to stick with CSocket rather than >CAsyncSocket, although this may mean forcing a TerminateThread >in case the user closes the application before the socket open >terminates. No, it wouldn't. First, nothing in the _world_ justifies the use of TerminateThread(). Second, if the user wants to close the application before the socket open terminates, you should post a quit message to the thread and get out. If the user has to wait, the user has to wait. They'd rather wait a bit than have you call TerminateThread() and damage their computer. >(I have read Mike's book, especially the section >about the dangers of TerminateThread.) Read it. I say the same thing there. I wasn't just moving my lips: TerminateThread() is bad news. You're better off letting the thread hang and telling the user that you have a hung thread and asking them to reboot because the system has become unstable. .B ekiM http://www.nwlink.com/~mikeblas/ These words are my own. I do not speak on behalf of Microsoft. One is too many and a million is not enough.
Become an MFC-L member | Вернуться в корень Архива |