Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。length:91と何度もなってしまいます。ターゲットのアプリケーションの最新版ではどの状況でも文字数が一致するのですが、古いバージョンでは上記のように一致する時としない時とあります。いった原因が考えられるでしょうか。以上、よろしくお願いいたします。追記:sbには実際の文字列が途切れて格納されていました。追記2:sbのCapacityは設定しておりましたが、転記ミスで抜けていました。ご回答いただいたのに大変失礼いたしました。10)しましたが、得られる文字列はやはり途切れておりました。票2WM_GETTEXTLENGTHに説明されています。Unicode.WindowsアプリケーションはUnicodeとANSIの2種類が存在し、APIとしてもUnicodeとANSIの2バージョンが用意されています。アプリケーションの動作モードとSendMessageとが異なる場合、実際の文字数ではなく文字列を格納可能な大きめのバッファサイズを返すそうです。sbには実際の文字列が途切れて格納されていました。CharSet.Auto)]としていますWM_GETTEXTLENGTHはANSIバージョンが呼び出された場合、当然ながらANSI文字列のバイト数を返しますし、WM_GETTEXTがWPARAMで要求するバッファサイズも呼び出したバージョンに依存します。ところがStringBuilderが保持するバッファのサイズは常にUnicodeの文字数です。質問文に挙げられているコードはバッファサイズの単位が一致しておらず非常に不安定です。Unicodeに統一すると共に、WM_GETTEXT呼び出し前にStringBuilderのバッファサイズを確保すべきです。StringBuilderの既定のバッファサイズは16文字ですのでたいていの場合にあふれています。CharSet.Auto)]としていますが、ループ中でANSIとUnicodeが変化してしまうこともあるのでしょうか。追記しましたが、取得された文字列は実際の文字列が途切れた状態でした。さん、追記部分にも回答しましたのでご確認ください。3:54Capacityは設定しておりましたが、転記ミスで抜けていました。ご回答いただいたのに大変失礼いたしました。5:02ありがとうございます。その辺りだと思われますので、検証し報告いたします。|0どういった原因が考えられるでしょうか。次の条件のもとでは、両戻り値に矛盾が無い場合も考えられます。(1)取得される側ウインドウがMBCS(=ANSI)で作られている。(2)取得する側ウインドウがUNICODEで作られている。この場合、(1)側は、WM_GETTEXTLENGTHに対してはMBCS単位での文字数(=BYTE数)を戻す。これをlength(=BYTE数)に代入します。後にWM_GETTEXT送付時の、バッファのUNICODE文字数として渡していることに注意。「そのMBCS文字数(=BYTE数)」を返却する。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。