I don't. If the compiler cannot convert to LPSTR, then it means you are compiling an ANSI build, not a UNICODE build, in which case you need to A. configure the project as a UNICODE build, or B. use stringstream instead of wstringstream.
Note that in order to extract the string contained in the stringstream (or wstringstream) object, you call for its str() method. Check the documentation in this site (left menu) and read about the string streams and its methods.
MessageBox() has a return type, yes. In my SDK, I see it returns an int, and the returned value represents the button that was pressed by the user.
Now, picking up the UNICODE topic: Functions that don't end in "A" or "W" are usually macro names (like MessageBox) that point to the real function name. Example: MessageBox is a macro that expands to MessageBoxA if UNICODE is not #defined. If UNICODE is #defined, then MessageBox expands to MessageBoxW. The ones that end in A take char's and related data types like LPSTR; the ones ending in W take wchar_t's and related data types like LPWSTR. Finally, the macro name actually takes TCHAR's and related data types like LPTSTR. The actual definition of a TCHAR is dependent on whether UNICODE has been #defined, just like the function macro names.
So, knowing the above, you must always follow these rules:
-If you call a function that ends in A, use the char data type and related types like LPSTR, LPCSTR and even the STL classes std::string and std::stringstream.
-If you call a function that ends in W, use the wchar_t data type and related types like LPWSTR, LPCWSTR and even the STL classes std::wstring and std::wstringstream.
-If you call a function that doesn't end in either, use the TCHAR data type and related types like LPTSTR, LPCTSTR and even the STL classes .... whooops!! No data type defined in the STL for this case, but you can define your own tstring and tstringstream data types like this:
1 2
|
typedef std::basic_string<TCHAR> tstring;
typedef std::basic_stringstream<TCHAR, char_traits<TCHAR>, allocator<TCHAR>> tstringstream;
|
If yoiu ALWAYS follow the rules above, you'll have no problem compiling either Unicode or ANSI builds of your software, regardless of how many code you see out there that doesn't follow these rules, including samples from the very Microsoft.