msdn:
http://msdn.microsof*****m/en-us/libr...=vs.85%29.aspx
Code:
HWND WINAPI FindWindow(
_In_opt_ LPCTSTR lpClassName,
_In_opt_ LPCTSTR lpWindowName
);
http://social.msdn.microsof*****m/For...rum=vclanguage
Brian says:
Code:
LPSTR = char*
LPCSTR = const char*
LPWSTR = wchar_t*
LPCWSTR = const wchar_t*
LPTSTR = char* or wchar_t* depending on _UNICODE
LPCTSTR = const char* or const wchar_t* depending on _UNICODE
LPCTSTR = const char* or const wchar_t* depending on _UNICODE
const char * vs. const wchar_t*
I think by using LPCSTR, "if(FindWindow(NULL, LPCSTR(s)))", you forced a call to FindWindowA() instead of FindWindowW() (mentioned above)? maybe?
Try calling FindWindowW() explicitly as mentioned above.
"\0x41a\0x43b\0x438\0x435\0x43d\0x442" //"Клиент"
0x41a = 1050 , 0000 0100 0001 1010
0x43b = 1083 , 0000 0100 0011 1011
0x438 = 1080 , 0000 0100 0011 1000
0x435 = 1077 , 0000 0100 0011 0101
0x43d = 1085 , 0000 0100 0011 1101
0x442 = 1090 , 0000 0100 0100 0010
if it was calling FindWindowA(), it would try to interperet it as ascii
00000100 , 00011010 , 00000100 , 00111011 , 00000100 , 00111000 , 00000100 , 00110101 , 00000100, 00111101 , 00000100 , 01000010 .
00000100 is 4, which isn't a displayable character in ascii. Maybe that's causing FindWindowA() to bug? Just a guess really.
edit: googled
ascii table and 4 is "EOT (end of transmission)". Probably not important, but made me lol. FindWindowA() could limit which characters are considered valid, but I'm not sure why it would return true :/
edit: I tried
and a few other things and couldn't get it to work. idk. disregard above text.
