EDIT：以下に掲載されたワーキングコードは、ワーキングコードがコメントアウトされています。 Win7で作成したのと同じCHAR_Tを使用して、ウィンドウからデータを取得する必要があります。Win7のSendMessageAとSendMessageWはWinXPから移行されました
WinXPで完全に動作するダイアログがありますが、Win7ではunicodeのエディットコントロールからユーザー入力を収集できません。以下に示すような問題は、SendMessageWの最初の呼び出し時に発生します。
/* handles to controls */
HWND hDomainEdit;
HWND hOtherEdit;
HWND hTextOut;
HWND hButton;
/* buffers to receive input */
WCHAR wszDomain[256];
CHAR szOtherInput[512];
CHAR szBuffer[512]; //added to hold temporary value of wszDomain
/* a test string */
const CHAR szTest[] = "This is a test of SendMessageA."
BOOL dialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) {
if (message == WM_INIT) {
/* get all the handles shown above, then... */
SendMessageA(hTextOut, WM_SETTEXT, 0, (LPARAM) szTest);
/* worked fine */
/* do a few other things */
} else if (message == WM_COMMAND) {
/* are some other conditions are true? they sure are */
/* time to collect a bunch of input from controls */
int cchResultLen = (int) SendMessageA(hOtherEdit, WM_GETTEXT, 512, (LPARAM) szOtherInput);
/* cchResultLen is correctly the length of the user input */
/* cchResultLen = (int) SendMessageW(hDomainEdit, WM_GETTEXT, 256, (LPARAM) wszDomain); */
/* begin new code */
cchResultLen = (int) SendMessageA(hDomainEdit, WM_GETTEXT, 512, (LPARAM) szBuffer);
cchResultLen = MultiByteToWideChar(CP_UTF8, 0, szBuffer, cchResultLen, wszDomain, 256);
wszDomain[cchResultLen] = 0; /* above doesn't terminate string */
/* after SendMessageW(), cchResultLen was 0, no string transferred, no error
message. using SendMessageA, all is well. */
}
}
SendMessageAがメッセージ= WM_GETTEXTまたはWM_SETTEXTで複数回作品現れ、突然、ワイド文字列が必要なとき、SendMessageWが失敗しました。さて、皆さんは、常にSendMessageを使ってCHAR_Tを選択してそれに固執すべきだと皆が考えていることを知っていますが、そうではありません。 Win32.hlpは、個々の関数を手動で呼び出すことにより、両方を同じプログラムで使用できることを明示的に示しています。他の誰かがコントロールそのものが特定のCHAR_Tにコミットしているとかコミットしていると言ってもいいですが、これは完全に機能するWinXPではそうではありません。その特定のエディットコントロールは、明示的にASCII文字列に設定されることもありません。
プログラムはWinHttpとやりとりし、WCHARのすべての文字列が必要です。それはSendMessageWが入る場所です。残りの入力は内部でのみ使用され、主に、ASCIIでより便利で効率的な単位ラベル付きの整数ですそれ以外の理由がない場合は、プログラムはもともとその方法で書かれていたからです。
だから何ですか？彼らは本当にSendMessageと一体不可分な何かを変えましたか？もしそうなら、それは回避策がある既知のバグですか、あるいは廃止予定の機能でCHAR_Tを切り替えることができますか？ SendMessageAで取得した後、手動で入力をWCHARに拡張するより簡単な方法がありますか？
私は、このエラーが 'SendMessageW（）'にないと思っています。少なくとも出発点として。 'hDomainEdit'が有効ですか？ 'SendMessageA'を使うとどうなりますか？また、なぜ 'GetWindowText [AW]'を使わないのですか？ – atzz
sayeth MSDN： "対象のウィンドウが現在のプロセスによって所有されている場合、GetWindowTextは指定されたウィンドウまたはコントロールにWM_GETTEXTメッセージを送信させます。それはほぼ同じ効果でなければなりません。私はハンドルの価値をチェックしようとします - それはその1つのステートメントの外で決して使用されないので、他のいくつかの問題は静かになるでしょう。しかし、それは間違いなくXPの正しいコントロールへの有効なハンドルです。 – sqykly
私はここでWM_GETTEXTを使うのが間違っていると言っているわけではありません。個人的には、そうしなければならない理由がない限り、API関数をメッセージに使用する方が好きです。また、MSDNはGetWindowTextがWM_GETTEXTを送信する以外に何かを行うかどうかを示していません。例えば。いくつかのニュアンスがあるかもしれません。ANSI/UNICODE変換（私は覚えていませんが）。 – atzz