How to obtain text in another application window

To obtain the text of another process window, send WM_GETTEXT directly.

CWnd* pWnd = GetOtherAppWindow();TCHAR buf[512];pWnd->SendMessage(WM_GETTEXT, sizeof(buf)/sizeof(TCHAR), (LPARAM)(void*)buf);

If you are programming in C, HWND is used instead of CWnd. Someone will certainly ask: Hey, wait a moment -- if this can be done, why does GetWindowText not work? Isn't WM_GETTEXT sent by GetWindowText? Also, GetWindowText sends WM_GETTEXT only when the window belongs to the current process; otherwise, it does something else. This document makes it clear: If the target window belongs to another process and has a window title, GetWindowText gets the window title text. If no window title exists, GetWindowText returns an empty string. This is a design behavior, that is, it is handled during design. In other words, you can get the title of the Main Window of another process, but you cannot get the text of the subwindow such as the edit box, combo box, or button in the window. Why? Why is this "design behavior? This document also explains: "It allows the application to call GetWindowText without suspending the process in which the target window is located." It's amazing, isn't it? GetWindowText provides the never-never land call protection. Of course, the old programmer may think: what's better? GetWindowText cannot be obtained. If you want to obtain the text, you must use SendMessage to send WM_GETTEXT, which may be suspended. So how can we protect it? Even if you do not use SendMessage! You can also use SendMessageTimeout. Even if the call enters a deadlock process, it will certainly return. In the multitasking world, there are too many complicated things to consider. The real question is: Why does the Microsoft guys not let the GetWindowText function do what it should do? That is to say, if the window is in the current process, why does GetWindowText do not send SendMessage (WM_GETTEXT) once, while the window does send SendMessageTimeout once in another process? Good question. Only the Window Wizard (Wizard) knows. I suspect that in the transition from a pseudo-multitasking to a real multitasking, the team at Microsoft had a hard time figuring out how to deal with the applications left behind ......

By convention, I wrote a small program GWTTest for demonstration. GWTTest displays the top-level window obtained from GetWindowText and SendMessageTimeout (WM_GETTEXT) and the text controlled by the editing box. 1:

Figure 1 Comparison Between GetWindowText and WM_GETTEXT

The GWTTest program is useless. It is only used to demonstrate the difference between GetWindowText and WM_GETTEXT. From the running results of the program, we can see that both operations can return the title of the top-level window, but only WM_GETTEXT can play a role in the edit box control of other processes. GWTTest is a simple CListView application. The function for retrieving text is CMyView: addjavaswinfo. The Code is as follows:

// Addmediawinfo. cpp source code //////////////// add window information. The top-level or edit box controls void CMyView: addjavaswinfo (int iItem, HWND hwnd) {CListCtrl & lc = GetListCtrl (); CWnd * pWnd = CWnd: FromHandle (hwnd); int iSubitem = 1; // Add the class name CString s ;:: getClassName (hwnd, s. getBuffer (STRINGLEN), STRINGLEN); lc. setItemText (iItem, iSubitem ++, s); // use GetWindowText to add the window text pWnd-> GetWindowText (s); lc. setItemText (iItem, iSubitem ++, s); // use WM_GETTEXT to add the window text DWORD result; SendMessageTimeout (hwnd, WM_GETTEXT, STRINGLEN, (LPARAM) s. getBuffer (STRINGLEN), 0, 1000, & result); lc. setItemText (iItem, iSubitem ++, s); s. releaseBuffer ();}