|Still, I'm convident I'm right on the redefinition.|
I wouldn't be. I'm still very skeptical.
|If I let the cursor linger momentarily over ASCII text functions while working on the source file, they all display messages like this.|
WinAPI functions such as MessageBox are defined as macros. This is due to the TCHAR issue.
MessageBoxA = takes char's
MessageBoxW = takes wchar_t's
MessageBox = takes TCHAR's
This is defined in the formal documentation on MSDN.
What's more, TCHAR is simply a typedef (or possibly a #define) of either char or wchar_t depending on whether or not the UNICODE macro is defined.
So instead of having an actual 3rd function, the TCHAR version of these functions are merely #defined over to the A or W versions, dependon on what TCHAR itself is defined as.
So this is not a matter of them redefining the behavior of existing functions. All the above work exactly as advertised -- exactly how the documentation says they should.
However... your problem is neither with a WinAPI function... nor is it with a function that takes TCHARs. So none of that applies.
I will test out the code you posted and revisit this momentarily....
Okay here is what I figured out.
1) wsprintf() is a WinAPI function that takes TCHARs
). Notice the parameter list says LPCT
STR. That T means TCHAR. It does not take wide characters (at least not all the time).
So yeah, wsprintf() is going to be defined as either wsprintfA or wsprintfW depending on whether or not UNICODE is defined. If you are not using TCHARs, you should not be using that function.
2) You are correct in that wsprintf does not seem to support floating point numbers. It appears to be a "mini" version of the actual sprintf. It also does not support the '*' qualifier, and truncates the string at 1024 TCHARs. So it's basically a steaming load and you shouldn't use it at all. Plus it's WinAPI so it's not portable.
3) swprintf works fine as you posted it for me. I don't know why you're having trouble but I can only assume that the code you are running is slightly different from what you pasted (you had some other issues with your code that I had to fix before running it -- such as a dot instead of a comma, and uninitialized variables).
If you don't give me and actual copy/paste of code that repos your problem, I can't verify it.
4) swprintf is a standard function (portable) whereas wsprintf is not (available on Windows only). Apart from that, swprintf actually works whereas wsprintf is crippled as previously described. So I cannot imaging any reason why anyone would ever choose wsprintf over swprintf.