S.l.e!ep.￠%

藍(lán)色：十分十分業(yè)余的翻譯
紅色：專業(yè)翻譯

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() 比你想象中的還在復(fù)雜. 相關(guān)的文檔嘗試用少量的詞解釋它的復(fù)雜性，這比用大量你不懂的詞要好得多，

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

Here's an attempt to give the full story.

這里嘗試介紹事情的始末

下面，我們就來講述 GetWindowText函數(shù)的完整內(nèi)容。

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.

窗體類管理它們的文字有兩種方法.它們不是通過手工或系統(tǒng)來管理.默認(rèn)是通過系統(tǒng)來管理

在窗口類中可以通過兩種方法來管理文本：即可以讓窗口自己管理，也可以讓系統(tǒng)進(jìn)行管理，默認(rèn)的情況是由系統(tǒng)進(jìn)行管理。

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

如果一個(gè) 窗體類讓系統(tǒng)管理它的文字，系統(tǒng)將做以下這些：

如果窗口類讓系統(tǒng)來管理文本，那么系統(tǒng)會(huì)進(jìn)行以下的這些工作：

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

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

對(duì)WM_NCCREATE消息進(jìn)行默認(rèn)的處理：將傳遞給CreateWindow/Ex 函數(shù)的參數(shù) lpWindowName提出出來, 并將這個(gè)字符串保存在某個(gè)“特殊位置”

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

WM_GETTEXT 默認(rèn)的處理函數(shù)從“特殊的地方”獲取字符串

對(duì)WM_GETTEXT消息進(jìn)行默認(rèn)的處理：從“特殊的位置”上提取字符串

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

WM_SETTEXT 消息的默認(rèn)處理函數(shù)復(fù)制字符串到“特殊的地方”

對(duì)WM_SETTEXT消息進(jìn)行默認(rèn)的處理：從字符串復(fù)制到“特殊的位置”

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.

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

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

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

框架窗體通常讓系統(tǒng)管理它們的窗體文本。自定義控件通常手動(dòng)管理它們的窗體文本

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

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 存在一個(gè)問題：窗體文本需要不會(huì)被掛住隨時(shí)都可以獲取.

在GetWindowText函數(shù)中有一個(gè)問題：函數(shù)需要迅束地得到窗體文本并且不會(huì)被掛起。

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

FindWindow 函數(shù)需要通過窗口文本來查找窗口

任務(wù)切換的各個(gè)應(yīng)用程序 需要獲取窗體文本，因?yàn)樗鼈円@示被切換的窗體文本

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

不能因?yàn)橐粋€(gè)阻塞的應(yīng)用程序阻礙到其它的應(yīng)用程序.特別是在任務(wù)切換的情況下.

某個(gè)掛起的程序阻塞其它應(yīng)用程序的情況是不應(yīng)該發(fā)生的，這就是任務(wù)切換程序所要面對(duì)的實(shí)際情況.

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.

在發(fā)送 WM_GETTEXT消息的情況下有爭(zhēng)議，因?yàn)槟繕?biāo)窗體的 WM_GETEXT可能被阻塞住. 或者，GetWindowText 能使用“特殊的地方”而不受阻塞著的應(yīng)用程序的影響.

這就要求不應(yīng)該發(fā)送WM_GETTEXT消息，因?yàn)?span lang="EN">WM_GETTEXT的目標(biāo)窗口可能被掛起。此時(shí)，GetWindowText應(yīng)該從“特殊位置”上獲取文本，因?yàn)檫@種做法不會(huì)受掛起程序的影響。

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 習(xí)慣于從對(duì)話框的控制中獲取文本.而且這些控件通常采用自己的文本管理.

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

發(fā)送WM_GETTEXT消息的爭(zhēng)議，因?yàn)槟鞘俏ㄒ猾@取自定義管理文本的途徑

因此，這又要求應(yīng)該發(fā)送ＷＭ_GETTEXT消息，因?yàn)檫@是獲取自定義管理文本的唯一方法

So GetWindowText strikes a compromise.

所以 GetWindowText采用折衷方案

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

• 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.

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

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

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

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

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.

根據(jù)第一條規(guī)則，如果你在自己的進(jìn)程中嘗試從窗體獲取文件，那么窗體將阻塞，然而 GetWindowText() 也將阻塞. （不懂翻譯）.發(fā)送WM_TEXT消息保證窗體的文本執(zhí)行自定義的文本管理（通常是自定義控件）將適當(dāng)?shù)鼗謴?fù)

根據(jù)第一條規(guī)則，如果你想要獲取自己進(jìn)程中的窗口文本，而這個(gè)窗口被掛起了，那么 GetWindowText 也會(huì)被掛起，不過因?yàn)檫@個(gè)窗體屬于你的進(jìn)程，所以函數(shù)掛起是你自己犯的錯(cuò)誤，并且你應(yīng)該為此負(fù)責(zé)。發(fā)送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.

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

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

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

文檔簡(jiǎn)單的認(rèn)為 GetWindowText 不能從另一應(yīng)用程序獲取文本

而在GetWindowText的幫助文檔中將上述內(nèi)容簡(jiǎn)化為“GetWindowText無法從另一應(yīng)用程序窗口中得到文本”

What if I don't like these rules?

( 不懂翻譯)

如果不喜歡這些規(guī)則，該怎么辦?

?

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.

如果第二條規(guī)則讓你感到很煩，因?yàn)槟阈枰獜钠渌M(jìn)程的自定義控制獲取文本.

然而你可以手工發(fā)送 WM_GETTEXT 消息，因?yàn)槟悴徽{(diào)用 GetWindowText() ，所以你不需要受它的規(guī)則約束。

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

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

注：然后，如果目標(biāo)窗體阻塞，你的應(yīng)用程序從調(diào)用 SendMessage() 開始也會(huì)阻塞不會(huì)返回，直到目標(biāo)窗體響應(yīng)。

注意：如果目錄窗口被掛起，那么你的應(yīng)用程序?qū)⑼瑯颖粧炱穑驗(yàn)?span lang="EN">SendMessage函數(shù)只有當(dāng)目標(biāo)窗體處理完這條消息時(shí)才會(huì)返回

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.

同樣需要注意的是，因?yàn)?span lang="EN"> WM_GETTEXT 是在系統(tǒng)消息范圍之內(nèi)，因此像把當(dāng)前進(jìn)程的緩沖區(qū)傳送到目標(biāo)進(jìn)程以及從目標(biāo)進(jìn)程將結(jié)果字符串返回到當(dāng)前進(jìn)程中等這些操作（這個(gè)過程也被稱為列集(marshalling)）,就不需要你自己進(jìn)行特殊的處理。事實(shí)上，無認(rèn)你采取什么樣的特殊處理，最終都是錯(cuò)誤的，窗體管理器將自動(dòng)將為你完成列集操作。

Can you give an example where this makes a difference?

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

Consider this control: 考慮下面這個(gè)控件

SampleWndProc(...)

{

??? case WM_GETTEXT:

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

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

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

??? ...

}

在應(yīng)用程序Ａ，我們進(jìn)行了以下操作

Now consider application A that does

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

在應(yīng)用程序Ｂ，這個(gè)進(jìn)程得到應(yīng)用程序Ａ的窗體句柄

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);

上面這段代碼將會(huì)返回 szbuf=”Frappy”，因?yàn)檫@是從“特殊位置”上獲得窗口文本，然面，下面的代碼

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

?