Hi, Just a Comment. I assume that you understand that each 'C' or 'CPP' File, gets compiled into One and only One '.obj' module. The Linker stitches all those 'Obj' modules together, to create an Exe or DLL, your Target. In doing so, your program needs to link with other libraries and DLL's already on the system. For Instance, your program uses the keyboard, and uses the mouse. You did not have to write the code inside your program to track the mouse movements, register the clicks, etc. That was already done by Microsoft, and comes as part of the Windows Package. Now, Microsoft wrote all that stuff, but, the compiler needs to know what is available from Microsoft, I.e.: the function and other specifications that the Windows API provides. These specifications are included in the System Headers. If you change these specifications to suit your own purpose, well, it Might work if you also 'Re Compiled Windows' If you mess with your system header files, you are actually telling your compiler that Windows works different than that it actually does. Your Compiler caught you out, and stopped you writing a disaster. #include files do not make your program larger, at most it slows down your compiler and linker All Software Engineers should Learn and Train Machine and Assembly Language, so as to really Understand how a computer Works Bram van Kampen

Well thats cool. Have not looked at it but: Thank you. Thank you for your time

Are any of these an issue? CodeProject Member FAQ[^] Thanks, Sean Ewington CodeProject

There is no requirement for handshaking on UDP so who is server and who is client is purely notional. In human perspectives it's like two people talking on a CB band and one claiming they are the server and the other the client. The answer is purely in the eyes of the beholder and it is completely meaningless to the operation. It is the EXACTLY the same situation you have two parties chatting using UDP and no-one is in control. Either party can choose a) not to send or b) not to listen and so the idea of who is server and who is client is pointless. Generally the thing that makes that decision is where the data is coming from and going to which has nothing to do with the protocol. However for any situation you gave me I could always argue the server is the other end to the one you choose (you just have to pick the right criteria). To give you an example consider SNMP packets sent from a router back to be logged to a central site (your ISP usually has a display log of your data usage using this). Is the SNMP server the central site or is it the router sending the SNMP packets? Well if you goto the router settings they will generally call themselves the SNMP server. Most likely your SNMP monitor software will also call itself a server because it has the database and is running on an actual server. So which is server and which is client .. well non-one cares it changes nothing :-) In vino veritas

Thank you. Thank you for your time

As I said, the AdditionalLibraryDirectories path is where it looks for the .LIB file at link time. At run time nothing in your project settings have any meaning to the Windows operating system. When the program loader starts your executable it looks for all the .DLL files that are required. It first looks in the directory where the executable is loaded from, and then in all the directories listed in your system's PATH environment variable. So you either copy your dll into the directory where the .exe file resides, or add its location to the PATH variable.

OK, I see that now. And I see why he did that. I often have a difficult time seeing the obvious. Thank you for pointing that out and taking the time to reply. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

:thumbsup:

Already answered in the ATL forum.

I presume you mean something like: void ShowError(DWORD dwError, PWSTR pszMessage, int maxMessageSize ) { if (dwError == 0) { dwError = GetLastError(); } if (FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS | FORMAT_MESSAGE_MAX_WIDTH_MASK, // don't include line breaks NULL, // no source message dwError, // message identifier MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // default language pszMessage, // address of message buffer maxMessageSize, // size of user supplied buffer NULL // optional parameter list ) == 0) { // unknown error code swprintf_s(pszMessage, maxMessageSize, L"Error code: %d (0x%X)", dwError, dwError); } } Which you call by: WCHAR szMessage\[512\]; ShowError(nErrorCode, szMessage, \_countof(szMessage)); wcout << "Exception: " << szMessage << endl;

And that is because DEFAULT_DlRECTORY is an array and passing it as an argument means the address of the first character is passed. Ok, I must confess to being ate up with the dumb ass there. Thank you for taking the time for a gentle kick in the butt. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

Here's another much more recent article about what you can do to find the error: Investigate crashes: c stack trace and dumps[^] The difficult we do right away... ...the impossible takes slightly longer.

MTU size dictates this... To figure out the system MTU size at run-time, in Linux use getsockopt() with IP_MTU. ip(7): IPv4 protocol implementation - Linux man page[^] Windows has a similar call but not sure if the MTU option is readily available. Keep in mind that every device that the packet touches will impose it's own MTU size restrictions on it and you can't necessarily control all of them (depends on setup of course). In another words, even if your device doesn't fracture a packet, another one down the line may choose to do so. There are ways to do "mtu" discovery to find the max size transferrable. Just something to be aware of.

Did that. Thank you. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

IIRC you get this - or at least a similar - chain of warnings/errors when your first include does not match the precompiled header setting for the file. Check that the precompiled header setting for this file actually is "stdafx.h", not another one.

bkelly13 wrote: and they disdain C++. Thanks for clarifying Bryan; seems you really are the one with the tough part of the job. bkelly13 wrote: dropping WCHAR and going to wchar_t Indifferent really, as WCHAR is just a typedef for wchar_t, probably a hangover from the days before C++. I know that going from ASCII to Unicode is initially a bit of a pain, but it is probably the right decision for the long term.

That was it. Thank you. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

See my better explanation below.

Ok, I am using that now, in stdafx.h Thank you for your time. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com