arack's solution won't work (don't cast around compiler errors!!!)
std::string is not a wide string. LPCWSTR is. You have 3 options (listed in the order in which I recommend them):
1) Use std::wstring instead of std::string. Then you have a wide string and can just do whatever.c_str();
2) Don't use SetDlgItemTextW() (which takes a wide string). Instead use SetDlgItemTextA() (which takes a non-wide string). Then you can just do whatever.c_str();
3) Manually copy your std::string to a wchar_t buffer (or to a std::wstring) -- typically this is done char-by-char in a loop -- or with one of the MultiByteToWideChar WinAPI functions, or one of the std lib functions that does the same thing (although I never understoo how they worked -- so I can't really help with how to use them and/or really recommend them). Then pass the copy to SetDlgItemTextW.
Note that there is absolutly no reason to do #3 unless the original string is UTF-8 encoded or something. If you're just going to do a naive char-by-char copy, then forget about #3 and just do #2 instead because Windows will do that automatically for you.
The way I see it, if you don't have a wide string to begin with, there's no reason for you to use the wide version of the WinAPI function.
I still find it surprising that all of the functions in the Win32 API can't take an actual string, they work with char mystring  = "whatever" but wont accept a string mystring("whatver") and instead require a pointer to the string with c_str()
Windows API introduce the infamous Hungarian notation which is so "un-friendly" at least to me.
In twenty years someone will say the same about camel case when we're off using the next big paradigm.
In C, you're always dealing with a lot more variables than you do in C++. And Windows C programming exposed you to huge WindProc functions with more variables than you'd see in any console app. Hungarian notation was a friendly convention for dealing with this explosion of names.