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 | Вернуться в корень Архива |