Is there any way to find which interface a UDP packet was received on? I can't rely on using the IP addresses since it is possible (and fairly common for out of the box setup) that the device I'm talking to has a misconfigured IP. In other words, If a new device out of the box has a 10.1.0.1 address and my NIC that I am using to plug into it has a 192.x.x.x address, my program will eventually try broadcasting to it and a reply will come back with source address 10.1.0.1 on that NIC. This is why I cannot use IP addresses to try to determine which interface received the message. Thanks, Dave

I have a pointer to the server object (the object that created the listener socket), and I call a function in that server object. No additional threads. Thank you for your time on this.

I'm using a single instance of the listener socket. Would that be enough to ensure the file is only written by one client at a time?

I have a simple server app that uses WritePrivateProfileString() when a client changes the status of a user. I want to protect against multiple 'change status' requests resulting in clashing file writes. The clients communicate with the server using UDP and the server uses a listener socket. The listener socket uses 'OnReceive()' to call a function to write to the data file. I've been using a temp file to write to and then delete the working file then rename the temp file. It works most of the time but once in a while the main data file is deleted and there is no temp file. It's a bug but I'm wondering if there is a better way? Thank you.

Following techniques described at http://tinyurl.com/25762x , I can retrieve a binary file in Firefox and retrieve it from the responseText field of the request response object. However, in IE, the responseText field is empty and the data I'm looking for is in the responseStream field. When running the Microsoft Script Editor, I can view this property and it shows as an array of BYTE with the correct length. However, I can't access it from JavaScript which doesn't have a BYTE data type. I'm looking for 1) a pure JavaScript technique which can get the binary data as a String as in Firefox or 2) a method to convert the BYTE array to a JavaScript String object using a small add-in such as an ActiveX control. Thanks for any advice you can provide.

I'm going to reply to my own question. It drives me nuts when people just say: never mind, I figured it out and leave it at that. Here's what I ended up doing: In my CXXXApp (CWinApp derived class), I override WinHelp() and replace WinHelp() with the following: //CWinApp::WinHelp(dwData,nCmd); CString szFile(m_pszHelpFilePath); char drive[_MAX_DRIVE]; char dir[_MAX_DIR]; char fname[_MAX_FNAME]; char ext[_MAX_EXT]; _splitpath(szFile,drive,dir,fname,ext); CString szChm; szChm.Format("%s%s%s.chm",drive,dir,fname); nCmd = HH_HELP_CONTEXT; ::HtmlHelp(AfxGetMainWnd()->m_hWnd,szChm,nCmd,dwData); I needed to have the platform SDK installed to get the htmlhelp.h and .lib files. With those added to my project, the help seems to work identically to the way it did with WinHelp (jumps to the right topic,...). If you see something that I may have overlooked or could be doing better, please let me know.

I thought this was going to be an easy one since the MSDN documentation seems to indicate that there is a CWinApp::HtmlHelp() member function. I have a feeling the MSDN I am using is meant for use with a newer version of Visual Studio 6. My CWinApp header does not have such a member function. Is there any other way to use Html Help in a VC6 project? I don't need to build the chm's - I just want to be able to call them (replace CWinApp::WinHelp()). Thanks, Dave

Thank you very much. I'm working on keeping my own copy of the data now. I appreciate the help.

I am curious about a situation I have run into. I am hacking a program that was originally meant to read/write serially (serial port) into using UDP. I'm trying to preserve as much of the original code as possible for reasons that I won't bother you with here. The situation is that a ReadCom() function is called with a specific number of bytes that the calling function wants. For example, when the buffer to be read from has 22 bytes in it, the ReadCom() may be called asking for only 16 bytes. Another ReadCom() will be called later asking for the remainder. When I replace the serial port reads with a recvfrom(), it looks like the entire UDP message is gone after the first read even though I only asked for a partial number of bytes. I have two people here telling me different things. One says this should not happen - it is a FIFO, another saying that any time a recvfrom call is made, the entire UDP packet is cleared. Which is it? The behaviour seems to match with it being cleared but I would like to know what you think. BTW - I have tried using the ioctl with FNIOREAD to see how many bytes are available and it does say that 0 are available on the second read.

When I use the listen() call, which socket (or will it be both?) will get the attempt to connect from the client? If I try to recv(), will the socket that is bound to the specific address get the data or will there be a race condition (first socket to read gets the data)?

Does anyone know what happens when you have a socket bound to INADDR_ANY and then have a second socket (both TCP or both UDP sockets) bound to a specific address? I am trying to add something to an existing program that has a TCP socket bound to INADDR_ANY. I need to add a TCP socket that listens to 127.5.0.1 (within the same executable). Will messages sent to 127.5.0.1 be handled by my new socket or will everything go through the existing socket bound to INADDR_ANY? I guess I can check the address on the existing socket and handle the messages based on that but I'd still like to understand how this works. Thanks, Dave

This one is really driving me nuts! I am creating a dialog using the following code: if (!::IsWindow(pPS->pDlg->m_hWnd)){ pPS->pDlg->Create(IDD_CFG_DLG, this); } HWND hwndParent = ::GetParent(pPS->pDlg->m_hWnd); The creation happens after the OnInitDialog() of the main application window (a dialog) and everything seems to return success except for the GetParent() call which I am expecting to return my main dialog's m_hWnd. The IDD_CFG_DLG does have the "CHILD" style set and no border if that matters (I don't think it does). I have also tried forcing the parent by calling SetParent() but even though it returns no error, the result is the same - the parent of the created dialog is still NULL! What am I doing wrong here? Thanks, Dave

I am building a dll that is supposed to be using Unicode but I am having some problems. I won't go into a lot of detail but here's a quick summary - I am using grid software that requires a CString to be passed into it's SetText() function. I have a structure that has the follwing member: struct MYSTRUCT{ TCHAR szDescription[512]; }; So, when I reach the point where I need to set my grid text, I use the following: CString szTxt(struct.szDescription); It fails indside the CString code in AllocBuffer() where it is actually doing the "new" call. I don't expect anyone to know how to solve this but one thing that jumps out at me is that when I type sizeof(TCHAR) into my watch window, it returns a value of 1. I was expecting 2. I have "UNICODE" and "_UNICODE" defined in the project settings. Any idea?

Here's what fixed the problem: We noticed that two copies of Rundll32.exe were running and when they were killed, things worked. We looked into what was causing the Rundll32 to be executed and found that the tray application for the NVidia software was responsible. Once that was removed from the startup, things worked fine on both PC's where the trouble was reported. Those people can no longer use the tray app for the video card but they didn't need it. So, do you think it's something NVidia is doing, RunDll32, or just Windows that is at the root of the problem? Why would my pointer being passed in WM_COPYDATA get corrupt due to this app running? Thanks for your help, Dave.

I'm not sure what that is. I'll see if I can find more info on it. Does that affect how the WM_COPYDATA message works?

I'm still having trouble with this. I have a dll that uses the WM_COPYDATA to send a struct to a mainframe window. The struct has some longs (4 I think) and a char[256]. This has been working and does work on about 90% of PC's. A few customers and some in-house people do not see the text that is being passed. After checking into it, I have found that the pointer to the lpCopyDataStruct is not correct on the machines that have the problem. I can see where my struct begins by doing a memory dump starting at the erroneous pointer and it is there but much further down the line (maybe 40-50 bytes?)than where the pointer says it should be. Can anyonne think of a reason why this works most of the time but fails on certain PC's? I have reports that some NT, 2000, and XP machines have this trouble but not everyone with those OS's have the problem. Uuugh!! Thanks, Dave

I noticed someone else mentioned a similar issue in the article you linked to. No answer posted unfortunately.

Well, I've looked into it a bit further. It is actually recieving the message but the pointer to the data seems to be off be quite a bit (haven't counted the offset yet). I can see the start of my struct in the dump but it is preceeded by a bunch of "junk". I really don't know why. I have one long and 2 int's followed by a char[256]. The long, int's and string are all in there but not at the correct starting point. Any ideas?

I have seen issues with something that works fine in all Windows OS's except some machines running 2000 or XP. I'm using a WM_COPYDATA to send text between windows. When it fails, messages that should appear do not. It is extremely hard to narrow it down further than that. Is anyone aware of any issues using this message on the newer OS's?

Thank you very much! That did it!