22:15お世話になってます。再度ですが、InputString関連で質問があります。現在、自プログラム内でDrawKeyInputStringの表示制限関連がうまくコントロールできないので、この掲示板の過去ログ「テキスト入力について」ht・tp://dxlib.o.oo7.jp/cgi/patiobbs/patio.cgi?mode=past&no=922のレスNo9(管理人さんの返信)のDrawOriginalInputStringを参考に表示の基本部分を作成しております。&#13008;(丸のなかにカタカナのア)のような文字、旧字体の一部など、環境依存(?)の文字と思われるものは自前表示のやり方だと変換文字列等がうまく表示できないようです。確定文字列もその文字が途中で入ってしまうとそこから表示が途切れてしまいます。いったものをDrawKeyInputStringのように問題なく表示するにはどういったこと(もしくは知識)が必要でしょうか。古い記事を持ち出してしまい申し訳ありませんが、よろしくお願いします。最近知った知識をひけらかしたい気持ちもわかりますが言葉遣いには気をつけましょう。22:09管理人さん、yumetodoさん、unicodeについての情報ありがとうございます。管理人さんのアドバイス通りにコードを変えて、とりあえずユニコードの文字を処理できるようにできました。サロゲートペアについては、それを意識して組まなければならなそうなところがあったので、管理人さんから提示いただいた関数を駆使して修正をしてみました。ソースコードの一部を貼らせていただきます。指摘や助言をいただければ幸いです。17:28yumetodoさんありがとうございます。21:28管理人さんありがとうございます。ループの最初の位置についての考え方について理解しました。ありがとうございます。非常に申し訳ないです。記録した値から次の行の先頭位置と行の文字列のサイズを計算するので、「ひとつ前の文字」の「サイズ」も必要になってます。行の最後の要素の位置を記録する、というのが正しい表現でしょうか・・あまりよくわかりません。する必要がありますもしかしたらバグ報告になるかもしれないので少し経緯を交えて記載させていただきます。GetDrawStringWidthToHandleについてですが貼り付けたコードのベースはSwordBout付属のToollib中のStringInput中のもので(そこでは一文字ごとのcharSizeが設定されていた)それを改造してマルチバイトで開発してたときに自分でもちょっと気になった個所です。マルチバイトでこの関数に全角のcharSizeを設定しますと、取得する値がなぜか大きくなりました。fontHandle);}で処理していました。(dispStrはstd::string型)unicodeに変えてもサロゲートペアかどうかにかかわらず実数の1で普通に取得できてる感じだったので気にはしておりませんでしたが、先ほどの指摘からcharSizeを設定して確認したところ、こちらは大きな値とはならないようで、サロゲートペアも普通に処理してました。今は「吉田(よしだ)」の吉の字の上が「土」のものを入力して確認してます。サロゲートペアの一覧も見つけたのでそれのコピペでも確認してます。場合は普通と思われる値が返ってくるようです。22:33(一覧の最終更新日が更新されてないので空投稿させていただきます。したらバグ報告になるかもしれないので少し経緯を交えて記載させていただきます。それを改造してマルチバイトで開発してたときに自分でもちょっと気になった個所です。23:53>『ひとつ前の文字の位置』と書いたのは私です、gmoさんが組まれたプログラムのコメントには>『ひとつ前の文字の位置』との記述はありません失礼しました。私がソースにコメントとして書いたのは「直前の文字位置」でした。言いたかったのは、実際記録してるのは何かというところで、ちゃんとしたコメントを当てていなかったということです。今は「直前の文字位置」でなく、「直前を区切り位置に」と表現すべきだったかなと思ってます。計算して一行ずつ描画してます。記録する「行の最後」について、最後の文字がサロゲートペアの場合「文字位置」で記録してしまうとその文字の後半のwchar_t分が抜けてしまい、先頭とサイズの割り出し双方に問題が出てしまいます。実数1の場合は0が、charSizeの場合は描画幅として正しいと思われる値が返ってきました。同様にunicode版にて、サロゲートペア文字一文字を評価する際、長さとして実数1、charSize(サロゲのため2が入る想定)の設定でそれぞれ動かしたところ、双方とも同じ値が返り、描画幅としては正しいと思われる値が返ってきました。Unicode版についての結果はDx.Lib現行バージョンと同じと思われます。サロゲートペア文字として使用した文字は前の返信で記載した「吉田」の吉の字(士の部分が土)です。unicodeのほうは変更なしが正しいのかどうか解らなかったため、このように記載させていただきました。言いたかったのは、実際記録してるのは何かというところで、ちゃんとしたコメントを当てていなかったということです。今は「直前の文字位置」でなく、「直前を区切り位置に」と表現すべきだったかなと思ってます。それぞれ動かしたところ、双方とも同じ値が返り、描画幅としては正しいと思われる値が返ってきました。_;municode版にて前回と同じテストを行いました。実数1の場合は0が、charSize(設定されたのは2)の場合は正しいと思われる値が返ってきました。修正作業お疲れ様です。正しかったのですね自分としてはそういう認識で、表示自体も問題らしい問題は出てないです。長引かせて申し訳ありませんが、もう一つ質問があります。聞くのが少し怖いですが・・unicode移行のための修正で、文節情報(IMEINPUTCLAUSEDATA)を扱ってる箇所は、dxlib.hのコメントにあるような「バイト」ではなくwchar_tの数として扱って意図通りの動きをするのですが、こちらはwchar_tの数という認識で問題ないでしょうか。(マルチバイト版ではコメント通り「バイト」で扱って意図通りの動きをしました。unicode版にて前回と同じテストを行いました。実数1の場合は0が、charSize(設定されたのは2)の場合は正しいと思われる値が返ってきました。修正作業お疲れ様です。長引かせて申し訳ありませんが、もう一つ質問があります。こちらはwchar_tの数という認識で問題ないでしょうか。)となりますご回答ありがとうございます。なんとなくですが、ライブラリをunicodeで使用するにあたっての前提というか決まり事が見えてきた気がします。実は「文字がうまく表示できない」以外にひとつ要望があったのですが、自分の課題も増えたのでそれを消化したあとに改めて要望させていただきます。よって解決とさせていただきます。管理人さん、yumetodoさんありがとうございました。yumetodoさんのサロゲートペアについての早くからの言及と、管理人さんからの具体的な修正方法のおかげで移行作業がスムーズにできました。(記事メンテ時に使用)クッキ。