text to LPTSTR?
I have a function that takes 'LPTSTR' as one of its input, but I am having a hard time
converting a string into it. What I need to do is create a string that holds the path to
a folder with a number at the end.
int n = 0;
string path = "c:\\myData\\Image_";
path += intToString(n++);
path += ".bmp";
But I am then unable to convert path into a 'LPTSTR'.
If it matters, the function I am trying to call is this one ( it works with the TEXT() )
c_str() of a std::string should give you a C style string.
Thank you fr your reply, but I have already tried that. It does not give an error, but it does not work (no file is saved)
Here is what I am "using"
std::string path = "C:\\Users\\Ole\\Documents\\test_";
temp << iter++;
path += temp.str();
path += ".bmp";
more efficient to build the whole string with stringstream:
Originally Posted by h3ro
LPTSTR - is pointer to buffer of TCHAR
temp << "C:\\Users\\Ole\\Documents\\test_" << iter++ << ".bmp";
std::string path (temp.str());
so when compiling in UNICODE - you get the wrong string...
you could use
std::wstringstream and std::wstring in this case
or if you want to have a code compilable two ways - use template version
basic_stringstream <TCHAR> and basic_string<TCHAR>
I just ended up with turning off UNICODE.
Why do Microsoft (and probably a lot of others) insist on creating new variable types for everything?
Simply because they can --- they are the big dog on the block!
I'd say it's more to do with the multiple language support. Unicode (in it's 16-bit character form) is much more suitable to asian, cyrillic and arabic languages [to give but a few examples], whilst the standard ANSI/ASCII is just barely able to support most European languages.
Originally Posted by kcpilot
Exactly, while you might not care that your software can run on any PC, no matter what language, for real businesses this is often essential. Plus it's a real pain to convert to Unicode later on, when you suddenly realize that you need it after all. ;)
Originally Posted by matsp
In this case, it's not a new variable type. It's a typedef (or #define) for char* or wchar*, depending on the UNICODE flag. This way, you can compile your program in UNICODE or ANSI, by just setting a single flag. Imagine the amount of work if you had to replace every single instance of "char" in your code with "wchar".
I don't think Microsoft created unicode, and I don't know if Microsoft was the one to set a "de facto" standard for mapping wide -> unicode in compilers targeting PC x86/x64, so the blame is misplaced.
I really think the lack is for teaching who tend to teach char by default, when they really should be teaching students to use wchar.