That bug appears only when linking statically, and is probably not the cause of the problem. For a solution on using a CSocket object in a thread different from the thread that created it, see "How to pass a socket connection between threads in an MFC application in Visual C++" at http://support.microsoft.com/kb/175668[^]. Basically, you need surround the thread hand-off with calls to CAsyncSocket::Detach() and CAsyncSocket::Attach(). Mike

Here is a very old (circa 1996) article that describes how to write an HTTP/1.0 server using MFC: "Write a Simple HTTP-based Server Using MFC and Windows Sockets" by Dave Cook, February 1996 issue of Microsoft Systems Journal, at http://www.microsoft.com/msj/archive/S25F.aspx[^]

The proper place to do all this is inside your override of the PreSubclassWindow() function. This function is called regardless of whether the control is created dynamically with a call to Create(), or on-the-fly with a dialog resource template and subclassed with the DDX_Control functions. See http://www.flounder.com/presubclasswindow.htm[^]

You might have solved your problem by now, but one other reason that CSocket sometimes appears to "freeze" is that another one of the "golden rules" of sockets is broken: Don't call Receive() multiple times inside of OnReceive(). The correct code will make exactly one single call to Receive() inside OnReceive(). MSDN advises that multiple calls to Receive() can cause the application to freeze. The same rule applies to CAsyncSocket() too. See "Mfcsocs.exe sample demonstrates how to communicate in a TCP connection in Visual C++" at http://support.microsoft.com/kb/185728[^], which talks about a situation in which there are no more FD_READs. The simple little word about the application "hanging" is so important that it should be in large red bold letters, but it's not. Mike

Xiangyang Liu wrote:

I can no longer find the article I read...

This might be the article you are thinking of: "Wicked Code: Running ASMX Web Services on STA Threads" by Jeff Prosise, October 2006 MSDN Magazine, at http://msdn.microsoft.com/msdnmag/issues/06/10/WickedCode/[^] Mike

If you are willing to use the parallel port for driving of the LED, as Kahan has suggested, then here's a good article that might help: "Parallel port interfacing made easy: Simple circuits and programs to show how to use PC parallel port output capabilities" at http://www.epanorama.net/circuits/parallel_output.html[^] Note that under current Windows OSs, the outportb() function is no longer usable, and indeed all functions that directly access the port are not usable. You will need a prot driver, as noted in the cited article. Mike

Try increasing the TCP window size, on both client and server, for both send and receive buffers. See SO_SNDBUF and SO_RCVBUF, in the Winsock docs. The buffers should be sized to approximately RTT (round trip time) times the bandwidth of the smallest pipe. So, you really need to get a good estimate of RTT (try ping), and it really doesn't matter if your Danish user has a huge pipe if you are shipping it up to him through a 1500/300 ADSL link. If you don't have access to code, there are some registry tweaks available as described (e.g.,) at "Windows 2000 TCP Performance Tuning Tips" at http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm[^]. There are lots of sites like that one (search on "SO_RCVBUF SO_SNDBUF RTT bandwidth"). The Win2k registry entries are the same in WinXP. Mike

I have no idea what you're talking about, but good luck with that.

This one's not mine. I came across it at http://www.experts-exchange.com/Operating_Systems/WinXP/Q_22150503.html[^], but it seems to fit the "subtle bugs" category and I wanted to share it here. The developer had an internationally-deployed application which, apparently after a version upgrade, began to fail reliably with the message "The application has requested the Runtime to terminate it in an unusual way." However, the failure occurred only in Europe; the failure was not reproducible in the US. He tried linking with the "/MAP" linker option, and changing his WinMain code to install an exception handler that would allow him to see where the failure occurred. However, the failure was occurring before any of his code was executed, so it was failing even before the exception handler could be installed. After a false lead involving a possible flaw in the Microsoft assert() code, he eventually traced the problem to an initialization of a static variable (which of course is initialized by the CRT before any of his code is executed). Here is the developer's explanation of the problem and his solution:

A Smart Developer wrote:

What it turned out to be was the initialization of a static variable to what amounted to a negative time for anyone east of Greenwich: static CTime distantPast = CTime(1970, 1, 1, 0, 0, 0); Once I set my time zone to Berlin, the debugger found the problem in about 5 sec. The fix was very simple (2-Jan-1970 serves fine as the "distant past" for my purposes).

His answer also suggests a good programming practice about initialization of date-related variables (i.e., January 2nd, not the 1st). Mike

If you want to use TCP, then you must write your code to accommodate partial sends and recvs, and also to accommodate multiple sends and recvs. There is no way around this. TCP is reliable but it's stream-based, not message-based. This means that TCP views the data as a simple stream of singular bytes, and it's up to the appication to decide what the bytes mean. Even if you could somehow check for availability of room in the send buffer, that information is completely unrelated to how the stack will ultimately send data out over the wire, and of course is totally unrelated to how the recipient stack will re-assemble data at the receiving side. UDP, on the other hand, is message-based. It will definitely preserve "messages" or "packets". However, unlike TCP, UDP is unreliable, in the sense that either the entire message will be delivered, or nothing at all will be delivered. You need to decide on your requirements. Mike

The basic advice is that you should make exactly one single call to Receive (which calls the underlying winsock recv() function) from inside your OnReceive function (which the MFC framework calls in response to an FD_READ notification). This advice can't be found in the MFC documentation, either for CSocket or for CAsnycSocket. It's found, however, in the documentation for the underlying Winsock functions. For example, see the documentation for WSAAsyncSelect() (which is the Winsock function that causes Windows-style messages to be posted to your application from the network stack) at http://msdn2.microsoft.com/en-us/library/ms741540.aspx[^], which includes this quote:

MSDN at WSAASyncSelect wrote:

With these semantics, an application need not read all available data in response to an FD_READ message — a single recv in response to each FD_READ message is appropriate. If an application issues multiple recv calls in response to a single FD_READ, it can receive multiple FD_READ messages. Such an application can require disabling FD_READ messages before starting the recv calls by calling WSAAsyncSelect with the FD_READ event not set.

The point of this is to suggest that you get closer to the Winsock API when you start programming for high-rate transfers. There a a few dozen of these "gotcha's" that you don't learn/know about when using the MFC classes, particularly the CSocket class. Personally, I would avoid CSocket. CAsyncSocket is fine, since it's reasonably close to the Winsock API, but you still need to understand the underlying API if you expect your program to work correctly. Mike

Is the following utility successful in getting the contents of the list view? FWIW, here is a clever utility that copies the text of another process's controls to the clipboard. The controls that are supported are Edit (including obscured password edits), Static, Headers, Listview, ComboBox and ListBox. Source code (GPL'd) is included: "Control Content Saver" by Jacquelin Potier at http://jacquelin.potier.free.fr/controlcontentsaver/[^] If the code at the above site works, whereas yours doesn't, then compare code. If the code at the site doesn't work either, then you might not be looking at an ordinary list view control. Are you 100% certain that the windows class is SysListView(32)? Double-check with Spy++. If it's definitely a SysListView, then also check the style flags. Maybe it's an owner-data (i.e., a virtual list view) or owner-drawn, or both. Mike

jnhemley wrote:

I'm trying ot compile a function that I developed and successfully compiled in Visual c++ 5.0 as well as on Unix. I need to compile it in a 16 bit DOS environment using sockets to interface it with an old Cobol program.

A bit off topic, but if you are using sockets, then why do you need to write 16 bit code? Sockets is just a stream of bytes, and the recipient Cobol code won't know or care that it was sent the stream from a 16 bit process or a 32 bit process, and your easier-to-write 32 bit code won't care how the reply stream was generated. Mike

I generally agree with Mark's observation that problems like this are almost always caused by code on the receiving side. Here, you have set the timeout for select() to 5 microseconds. That's way too short. Your understanding of the send() function is slightly wrong. send() does not actually send bytes out over the wire; that happens later when the winsock TCP stack determines that it's time to send data on the wire, after considertion of things like Nagle, delayed ACK etc. Rather, a successful call to send() only indicates that the winsock stack has successfully transferred data in your user buffer to its internal winsock buffer. The return value from send() tells you exactly how much of your buffer has been accepted; you should therefore inspect the returned value to ensure that winsock transferred everything to its internal buffer. So, if you are debugging and single-stepping through your code, and you see a successful completion of the call to send(), then it's probably still too early for a sniffer to see the actual data on the wire. That will happen, but it will happen at some indeterminate time in the future. Mike

I didn't realize it was the OP's code (which was so long and unformatted that I barely even glanced at it). Sorry. Mike

wrote:

I want to know what is the reason behind this?? why such difference in Debug and Release build ??

Stack corruption causes the crash. The correct signature of a message handler, the function takes a WPARAM and an LPARAM (which are pushed onto the stack when the function is called) and returns an LRESULT (which is popped from the stack when the function returns). In the incorrect version of your code, the fun() function is being called as if it had this signature, even though the fun() function does not, and as a result there is stack corruption. The fact that it works in debug mode is a coincidence, possibly due to padding added by the compiler in debug compilations. Incidentally, are you still using VC 6.0? The error in signatures for message handlers is flagged as a compiler error in newer versions of Visual Studio. Mike

Don't use a switch statement to check the network event. More than one event can be signalled at a time. The events will be OR'd together. Mike

See this article by Paul DiLascia, from his "C++ Q&A" column in the October 2004 issue of MSDN: "Create Client Windows, Drag and Drop Between Listboxes" at http://msdn.microsoft.com/msdnmag/issues/04/10/CQA/[^] It explains the coding needed to obtain drag and drop between different list boxes in the same application. Mike

jhwurmbach wrote:

I had been misled by the debugger (VC2003), which is capable of showing the virtual variable (TYPEB, TYPEC) when the mouse is hovering over pA.

What is a "virtual variable"? I don't think that there is any such beast. Mike

For all string literals in your code, you should use the _T("xxx") macro. For unicode builds, _T() is replaced by 'L', whereas for non-unicode builds it gets replaced by white space. So, literals end up correctly defined automatically, regardless of the build. Mike