藍色：十分十分業余的翻譯
紅色：專業翻譯

The secret life of GetWindowText

GetWindowText 的秘密生活

GetWindowText 的秘密

GetWindowText() is more complicated than you think. The documentation tries to explain its complexity with small words, which is great if you don't understand long words, but it also means that you're not getting the full story.

GetWindowText() 比你想象中的還在復雜. 相關的文檔嘗試用少量的詞解釋它的復雜性，這比用大量你不懂的詞要好得多，

GetWindowText() 函數遠比你想象中的要復雜.在GetWindowText函數幫助文檔中試圖通過簡短的文字來解釋這個函數的復雜性，如果你無法理解一些長篇大論的文字，那么這種做法無疑是很好的，但簡短的文字同樣意味著整個內容會變得晦澀難懂。

Here's an attempt to give the full story.

這里嘗試介紹事情的始末

下面，我們就來講述 GetWindowText函數的完整內容。

How windows manage their text

Window 如何管理它們的文字

窗體如何來管理文本

There are two ways window classes can manage their text. They can either do it manually or they can let the system do it. The default is to let the system do it.

窗體類管理它們的文字有兩種方法.它們不是通過手工或系統來管理.默認是通過系統來管理

在窗口類中可以通過兩種方法來管理文本：即可以讓窗口自己管理，也可以讓系統進行管理，默認的情況是由系統進行管理。

If a window class lets the system manage its text, the system will do the following:

如果一個 窗體類讓系統管理它的文字，系統將做以下這些：

如果窗口類讓系統來管理文本，那么系統會進行以下的這些工作：

• Default handling of the WM_NCCREATE message takes the lpWindowName parameter passed to CreateWindow/Ex and saves it in a "special place".

WM_NCCREATE 消息的默認處理函數將lpWindowName 參數傳給 CreateWindow/Ex 并且將它保存在 “特殊的地方”

對WM_NCCREATE消息進行默認的處理：將傳遞給CreateWindow/Ex 函數的參數 lpWindowName提出出來, 并將這個字符串保存在某個“特殊位置”

• Default handling of the WM_GETTEXT message retrieves the string from that "special place".

WM_GETTEXT 默認的處理函數從“特殊的地方”獲取字符串

對WM_GETTEXT消息進行默認的處理：從“特殊的位置”上提取字符串

• Default handling of the WM_SETTEXT message copies the string to that "special place".

WM_SETTEXT 消息的默認處理函數復制字符串到“特殊的地方”

對WM_SETTEXT消息進行默認的處理：從字符串復制到“特殊的位置”

On the other hand, if a window class manages its window text manually, the system will not do any special handling, and it is the window class's responsibility to respond to the WM_GETTEXT/WM_SETTEXT messages and return/save the strings explicitly.

另一方面, 如果一個 窗體類手工管理它的窗體文本，系統將不會做任何特殊處理，（不懂翻譯）

另一方面，如果是由窗體類自己來管理窗體的文本，那么系統將不會做任何特殊處理，而是由窗體類來負責響應WM_GETTEXT/WM_SETTEXT消息，并且直接返回/保存字符串。

Frame windows typically let the system manage their window text. Custom controls typically manage their window text manually.

框架窗體通常讓系統管理它們的窗體文本。自定義控件通常手動管理它們的窗體文本

框加窗口（Frame Windows）通常由系統來管理窗口中的文本，而自定義控制通常由它們自己來管理窗口中的文本

GetWindowText

GetWindowText has a problem: Window text needs to be readily available without hanging. FindWindow() needs to get window text in order to find a window. Task-switching applications need to get window text so they can display the window title in the switcher window. It should not be possible for a hung application to clog up other applications. This is particularly true of the task switcher scenario.

GetWindowText 存在一個問題：窗體文本需要不會被掛住隨時都可以獲取.

在GetWindowText函數中有一個問題：函數需要迅束地得到窗體文本并且不會被掛起。

FindWindow() 需要通過獲取窗體文本來找到一個窗體

FindWindow 函數需要通過窗口文本來查找窗口

任務切換的各個應用程序 需要獲取窗體文本，因為它們要顯示被切換的窗體文本

而任務切換程序也需要獲取窗口文本，以便在切換器窗口中顯示窗體的標題

不能因為一個阻塞的應用程序阻礙到其它的應用程序.特別是在任務切換的情況下.

某個掛起的程序阻塞其它應用程序的情況是不應該發生的，這就是任務切換程序所要面對的實際情況.

This argues against sending WM_GETTEXT messages , because the target window of the WM_GETTEXT might be hung. Instead, GetWindowText should use the "special place" since that cannot be affected by hung applications.

在發送 WM_GETTEXT消息的情況下有爭議，因為目標窗體的 WM_GETEXT可能被阻塞住. 或者，GetWindowText 能使用“特殊的地方”而不受阻塞著的應用程序的影響.

這就要求不應該發送WM_GETTEXT消息，因為WM_GETTEXT的目標窗口可能被掛起。此時，GetWindowText應該從“特殊位置”上獲取文本，因為這種做法不會受掛起程序的影響。

On the other hand, GetWindowText is used to retrieve text from controls on a dialog, and those controls frequently employ custom text management. This argues for sending WM_GETTEXT messages, because that is the only way to retrieve custom-managed text.

另一方面，GetWindowText 習慣于從對話框的控制中獲取文本.而且這些控件通常采用自己的文本管理.

另一方面，GetWindowText也用于從對應框的控制中提取文本，而這些控件通常使用的是自定義的文本管理機制。

發送WM_GETTEXT消息的爭議，因為那是唯一獲取自定義管理文本的途徑

因此，這又要求應該發送ＷＭ_GETTEXT消息，因為這是獲取自定義管理文本的唯一方法

So GetWindowText strikes a compromise.

所以 GetWindowText采用折衷方案

于是，在 GetWindowText 函數中采取了一種折中的方法

• If you are trying to GetWindowText() from a window in your own process, then GetWindowText() will send the WM_GETTEXT message.
• If you are trying to GetWindowText() from a window in another process, then GetWindowText() will use the string from the "special place" and not send a message.

如果你嘗試從一個你自已的進程的窗體 GetWindowText() ,那么 GetWindowsText() 將發送一個 WM_GETTEXT 消息

如果是同一進程的窗口中得到窗口文本，那么GetWindowText() 將發送 WM_GETTEXT 消息

如果你嘗從其它進程的窗體 GetWindowsText(), 那么GetWindowText將從”特殊地方”使用字符串，而不會發送消息

如果是從另外一個進程中的窗體中得到窗口文本，那么GetWindowText將會在“特殊位置”上獲取字符串，而不是發送消息

According to the first rule, if you are trying to get text from a window in your own process, and the window is hung, then GetWindowText() will also hang. But since the window belongs to your process, it's your own fault and you deserve to lose. Sending the WM_GETTEXT message ensures that text from windows that do custom text management (typically, custom controls) are properly retrieved.

根據第一條規則，如果你在自己的進程中嘗試從窗體獲取文件，那么窗體將阻塞，然而 GetWindowText() 也將阻塞. （不懂翻譯）.發送WM_TEXT消息保證窗體的文本執行自定義的文本管理（通常是自定義控件）將適當地恢復

根據第一條規則，如果你想要獲取自己進程中的窗口文本，而這個窗口被掛起了，那么 GetWindowText 也會被掛起，不過因為這個窗體屬于你的進程，所以函數掛起是你自己犯的錯誤，并且你應該為此負責。發送WM_GETTEXT消息將確保我們能夠正確地得到那么使用自定義文本管理方式的文本

According to the second rule, if you are trying to get text from a window in another process, then GetWindowText() will not send a message; it will just retrieve the string from the "special place". Since the most common reason for getting text from a window in another process is to get the title of the frame, and since frame windows typically do not do custom window text manipulation, this usually gets the right string.

根據第二條規則, 如果你嘗試從其它進程獲取窗體文本, GetWindowText() 就不會發送消息; 它只是從“特殊的地方”取回字符串.從另一進程獲取文本很多情況下是從框架獲取標題，(不懂翻譯)

根據第二條規則，如果想要獲得另一進程中的窗口文本，那么 GetWindowText() 將不會發送消息，而只是從“特殊位置”上獲取字符串，通常使用最多的方式是獲取另一個進程的框架窗口文本，而在框架窗體中一般不會使用自定義的窗口文本管理方式，因此往往能夠獲取到正確的字符串。

The documentation simplifies this as "GetWindowText() cannot retrieve text from a window from another application."

文檔簡單的認為 GetWindowText 不能從另一應用程序獲取文本

而在GetWindowText的幫助文檔中將上述內容簡化為“GetWindowText無法從另一應用程序窗口中得到文本”

What if I don't like these rules?

( 不懂翻譯)

如果不喜歡這些規則，該怎么辦?

?

If the second rule bothers you because you need to get text from a custom control in another process, then you can send the WM_GETTEXT message manually. Since you are not using GetWindowText(), you are not subject to its rules.

如果第二條規則讓你感到很煩，因為你需要從其它進程的自定義控制獲取文本.

然而你可以手工發送 WM_GETTEXT 消息，因為你不調用 GetWindowText() ，所以你不需要受它的規則約束。

如果你不喜歡第二條規則，例如希望得到另一進程中自定義控件的文本，那么可以自己發送ＷＭ_GETTEXT消息。此時，由于沒有使用 GetWindowText() 函數，因此就不受這條規則的約束。

Note, however, that if the target window is hung, your application will also hang since SendMessage() will not return until the target window responds.

注：然后，如果目標窗體阻塞，你的應用程序從調用 SendMessage() 開始也會阻塞不會返回，直到目標窗體響應。

注意：如果目錄窗口被掛起，那么你的應用程序將同樣被掛起，因為SendMessage函數只有當目標窗體處理完這條消息時才會返回

Note also that since WM_GETTEXT is in the system message range (0 to WM_USER-1), you do not need to do any parameter marshalling (and in fact, you shouldn't). USER will do the marshalling for you.

同樣需要注意的是，因為 WM_GETTEXT 是在系統消息范圍之內，因此像把當前進程的緩沖區傳送到目標進程以及從目標進程將結果字符串返回到當前進程中等這些操作（這個過程也被稱為列集(marshalling)）,就不需要你自己進行特殊的處理。事實上，無認你采取什么樣的特殊處理，最終都是錯誤的，窗體管理器將自動將為你完成列集操作。

Can you give an example where this makes a difference?

你能否給出一個說明這種差異的示例？

Consider this control: 考慮下面這個控件

SampleWndProc(...)

{

??? case WM_GETTEXT:

??????? lstrcpyn((LPTSTR)lParam, "Booga!", (int)wParam);

??????? return lstrlen((LPTSTR)lParam);

??? case WM_GETTEXTLENGTH: return 7; // lstrlen("Booga!") + null

??? ...

}

在應用程序Ａ，我們進行了以下操作

Now consider application A that does

hwnd = CreateWindow("Sample", "Frappy", ...);

在應用程序Ｂ，這個進程得到應用程序Ａ的窗體句柄

Now consider process B that gets the handle to the window created by application A (by whatever means).

TCHAR szBuf[80];

GetWindowText(hwnd, szBuf, 80);

上面這段代碼將會返回 szbuf=”Frappy”，因為這是從“特殊位置”上獲得窗口文本，然面，下面的代碼

This will return szBuf = "Frappy" because it is getting the window text from the "special place". However,

SendMessage(hwnd, WM_GETTEXT, 80, (LPARAM)szBuf);

將返回szBuf = "Booga!"

will return szBuf = "Booga!"

Published Thursday, August 21, 2003 9:30 AM by oldnewthing

Filed under: Code

?