win API: TEXT and wsprintf

[jmbauer1]

how can i translate this to c++ and use it in win API

TextOut (hdc, x + 22 * cxCaps + 40 * cxChar, y, szBuffer,
	 wsprintf (szBuffer, TEXT ("%5d"),
	 GetSystemMetrics (sysmetrics[i].iIndex))) ;

This is from the Windows Programming book and the author uses C

[jmbauer1]

I also herd that TEXT and TCHAR are outdated and don't need to be used anymore

[webJose]

1. That function call seems dangerous. I believe the C++ standard doesn't define the order of evaluation of arguments in function calls, and the code you present assumes that the order is right to left. This is not guaranteed by the standard and therefore is a call for trouble. The buffer needs to be prepared first, and then used. Two separate function calls in two separate lines.

2. wsprintf() is a function call that formats data into strings. You can use a std::wostringstream object and operator<< instead. That would be the C++ way of doing it.

3. You kindof heard wrong. TEXT, TCHAR and all related stuff is quite current. It is true, though, that ANSI builds are no longer necessary, unless you are still programming for Windows 95, 98, or ME. Therefore you can simply resort to using all-Unicode data types and functions. If you want to stop usage of T-stuff, you can. In the code above, replace TextOut with TextOutW, make sure szBuffer is a buffer of WCHAR's (Windows typedef for wchar_t in most instances), and TEXT("%5d") would have been replaced by L"%5d", but since you're changing that function call, I guess that part isn't going to need conversion.

Oh, and I guess that szBuffer can be of type std::wstring to move further down the C++ line.

EDIT: I think we can scratch point 1 above. I guess I wasn't seeing this right. The buffer will be used inside the function, not before while the arguments are being prepared. Since wsprintf() needs to be executed in order to determine the argument's value, it is guaranteed to go first, so yes, #1 above is nonsense. My bad.

[jmbauer1]

it won't let me use the std:wstring for szBuffer, it's saying must be type LPWSTR. That's not really a concern of mine though I know about cstrings. But im still confused on the wsprintf could you rewrite that TextOut using a c++ approach

[Perman]

That's weird. It works fine for me. Remember to include windows.h.
Maybe I don't understand your question'
Here is my code.

        case WM_COMMAND:{
            if(((HWND)lParam) && (HIWORD(wParam) == BN_CLICKED)){
                int iMID;
                iMID = LOWORD(wParam);
                switch(iMID){
                   // Button clicked
                    case ID_BUTTON:{
                        iValue = 3;
                        wsprintf(szMessage, "*** This is my program *** %d", iValue);
                        iXpos = 10;
                        iYpos = 40;
                        // Write string in window by sending message WM_PAINT
                        InvalidateRect(hWnd, NULL, NULL);
                        break;
                    }
                    default:
                    break;
                }
            }
            break;
        }
 

Message handler.

        case WM_PAINT:
            WriteText(iXpos, iYpos, szMessage);
            break;

This is the write text called from case WM_PAINT.

void WriteText(int _Xpos, int _Ypos, char *_szMessage)
    {
        hdc = BeginPaint(hWnd, &ppaint);
        // Here you can set the color of the string
        //SetTextColor(hdc, RGB(0,0,0));
        TextOut(hdc, _Xpos, _Ypos, _szMessage, strlen(_szMessage));
        EndPaint(hWnd, &ppaint);
    }

[webJose]

If you want to convert a number to a string, you use this:

std::wostringstream ss;
ss << theNumber;
//Now the string stream contains what you want.  You can get it in a form of a std::wstring like this:
std::wstring myData = ss.str();
//Now you have an STL string object with the data you want/need.
//Now you can use it with the Windows API functions that request a string, like TextOutW():
TextOutW(hDC,...., myData.c_str(), -1);

[jmbauer1]

ooooooh ok now it makes sense, thanks