TCHAR[], LPWSTR, LPTSTR and GetWindow Text function

So the GetWindowText is declared on MSDN as follows:

int GetWindowText(      
    HWND hWnd,
    LPTSTR lpString,
    int nMaxCount
);

However for the code to work we have to declare the second parameter as

TCHAR[255] WTitle;

and then call the function GetWindowText(hWnd,Wtitle,255); The LPTSTR is a pointer to an array of tchar, so declaring LPTSTR is similar to declaring TCHAR[]? It doesn't work this way though. When using TCHAR[] the program returns valid GetWindowText result (it is an integer equal to the number of symbols in the title). The question is : how can I get the exact title out of TCHAR[] ? Code like

TCHAR[255] WTitle;
cout<< WTitle;

or

cout<< *Wtitle;

returns numbers. How can I compare this with a given string?

TCHAR[4] Test= __T("TEST")
if (WTitle == Test) do smth

doesn't 开发者_如何学JAVAwork also.

Wow, let's see where to start from.

First off, the declaration of WTitle needs to look like this:

TCHAR WTitle[255];

Next, if cout is not working write, it's because you are in Unicode mode so you need to do this:

wcout << WTitle;

Or to fit better with the whole tchar framework, you can add this (actually, I'm surprised that this is not already part of tchar.h):

#ifdef _UNICODE
    #define tcout wcout
#else
    #define tcout cout
#endif

and then use:

tcout << WTitle;

OK, a few definitions first.

The 'T' types are definitions that will evaluate to either CHAR (single byte) or WCHAR (double-byte), depending upon whether you've got the _UNICODE symbol defined in your build settings. The intent is to let you target both ANSI and UNICODE with a single set of source code.

The definitions:

TCHAR title[100];
TCHAR * pszTitle;

...are not equivalent. The first defines a buffer of 100 TCHARs. The second defines a pointer to one or more TCHARs, but doesn't point it at a buffer. Further,

sizeof(title) == 100   (or 200, if _UNICODE symbol is defined)
sizeof(pszTitle) == 4  (size of a pointer in Win32)

If you have a function like this:

void foo(LPCTSTR str);

...you can pass either of the above two variables in:

foo(title);    // passes in the address of title[0]
foo(pszTitle); // passes in a copy of the pointer value

OK, so the reason you're getting numbers is probably because you do have UNICODE defined (so characters are wide), and you're using cout, which is specific to single-byte characters. Use wcout instead:

wcout << title;

Finally, these won't work:

TCHAR[4] Test == __T("TEST")   ("==" is equality comparison, not assignment)
if (WTitle == Test) do smth    (you're comparing pointers, use wcscmp or similar)

Short answer: Unless you're coding for Win98, use wchar_t instead of TCHAR and wcout instead of cout

Long version:

The TCHAR type exists to allow for code to be compiled in multiple string modes. For example supporting ASCII and Unicode. The TCHAR type will conditionally compile to the appropriate character type based no the setting.

All new Win systems are Unicode based. When ASCII strings are passed to OS functions, they are converted to unicode and the call the real function. So it's best to just use Unicode throughout your application.

Use _tcscmp or a variant (which takes in the number of characters to compare). http://msdn.microsoft.com/en-us/library/e0z9k731.aspx

Like:

if (_tcscmp(WTitle, Test) == 0) {
    // They are equal! Do something.
}

In C, wchar_t is a typedef for some integer type (usually short int). In C++, it's required to be a separate type of its own -- but Microsoft's compilers default to using a typedef for it anyway. To make it a separate type of its own, you need to use the /Zc:wchar_t compiler switch. Offhand, I don't know if that will entirely fix the problem though -- I'm not sure if the library has real overloads for wchar_t as a native type to print those out as characters instead of short ints.

Generally speaking, however, I'd advise against messing with Microsoft's "T" variants anyway -- getting them right is a pain, and they were intended primarily to provide compatibility with 16-bit Windows anyway. Given that it's now been about 10 years since the last release in that line, it's probably safe to ignore it in new code unless you're really sure at least a few of your customers really use it.