表示文字列の最右下端のＸとＹ位置を知りたいのですが。

[unknown]

文字サイズを大きくして例えば34ポイントサイズで表示し、
これらをＩＭＭの変換ウインドウと重ね合わせています。
変換中の文字サイズと変換後の文字サイズはどちらも
34ポイントにしています。
見にくいので、変換ウインドウを確定後の位置に毎回
移動したいと考えています。
　そこで実現するためには表示完了した文字の直後に
変換ウインドウを移動する必要があります。
　TextOutで表示する際は開始位置のｘとｙを指定しますが、
表示完了して時点たとえば
「あいうえお」とすると「お」の右下端の位置が知りたい場合に
どうすれば良いでしょうか。一発で取り出すＡＰＩがあれば
助かるのですが。なければ表示文字列の長さを計算する
ことから始めなければなりませんか。

[UETA, Shin-ichi]

こんにちは、植田です。

Post by unknown
「あいうえお」とすると「お」の右下端の位置が知りたい場合に
どうすれば良いでしょうか。一発で取り出すＡＰＩがあれば
助かるのですが。なければ表示文字列の長さを計算する
ことから始めなければなりませんか。

単純に考えると、状況に応じて

・GetTextExtentPoint32
・GetTabbedTextExtent
・DrawText(DT_CALCRECT)

―― のどれかを使って描画範囲を求めることになるのでは?

[unknown]

植田さん、早速の回答ありがとうございます。
上田です。

ご示唆頂いた中から「GetTextExtentPoint32」を使って見ました。
この関数から横サイズは全角1文字で１６、縦サイズで１８と
与えられました。１文字増える度に横が＋１６されます。縦は
ずっと１８のままでした。これでこの関数からは文字数に応じて
横サイズが変わることが確認できました。
　ところで横サイズの１６の意味ですが、色々と実測したり、
計算したりして次の通りの意味でないか結論になりました。
１６は文字ポイントサイズに関わらず一定で、１２ポイントでの
ピクセルの長さを表しているとなりました。
これで正しいでしょうか。（使用画面は１０２４×７６８）
　１６＝１２×９６（dpi）／　７２

Post by UETA, Shin-ichi
・GetTextExtentPoint32
・GetTabbedTextExtent
・DrawText(DT_CALCRECT)

[UETA, Shin-ichi]

どうも、植田です。

Post by unknown
　ところで横サイズの１６の意味ですが、色々と実測したり、
計算したりして次の通りの意味でないか結論になりました。
１６は文字ポイントサイズに関わらず一定で、１２ポイントでの
ピクセルの長さを表しているとなりました。

ん～、DCにアタッチされているフォントに合わせて計算結果は
変わってくるかと思うのですが、その辺りは間違いないですか?
12ptはデフォルトでアタッチされているフォントのサイズのよう
にも思えます。

また、プロポーショナルフォントだと必ずしも一定の幅では増え
ていかないかもしれませんし、全角と半角の混在も考慮しなけ
ればならないので、1文字につき n ピクセル増える ―― なんて
決め打ちはできないでしょうね。

# 固定ピッチのフォントしか使わないテキストエディタみたいな
# アプリケーションならともかく...。

ちなみに、ポイント数からピクセル数への変換については、
LOGFONT構造体のlfHeightの解説にある計算式（計算結果
の符号はlfHeight に固有の意味があるのでそれは除きます）
が参考になるはずです。

# 12pt * 96dpi / 72 がまさにそれです。

[unknown]

植田さん、いつもありがとうございます。

変換ウィンドウについて、検証していくと色々と判ってきました。
12ポイントサイズの応じての実際のピクセル単位は
縦が18、横が16
ポイントサイズの比例させれば、実際のピクセル長になること
表示位置とは４ピクセル連れていること
横幅はスペースを考えて実際は+1、つまり12ポイントなら17で
あることなどです。
又日本語入力に入るとkey_downには1cha毎に229が送信されて
来る事などです。
何故か判らないけど、keychaｒでとkey_downで変換ウィンドウの
位置が1文字分12ポイントなら17ピクセル連れていることなどで。

又、何故かＡｔｏｋでは変換ウィンドウでの字体が縦長（縦倍角のような）
字体になります。又文字がブルーになっています。
最近の一太郎は知らないのでちょつとびっくりしています。

[UETA, Shin-ichi]

どうも、植田です。

Post by unknown
横幅はスペースを考えて実際は+1、つまり12ポイントなら17で
あることなどです。

GetTextMetrics で TEXTMETRIC を取り出せば正確な情報が
得られると思いますよ。
詳しくはこれ↓をご覧ください。
http://msdn.microsoft.com/en-us/library/dd144835(VS.85).aspx

Post by unknown
又日本語入力に入るとkey_downには1cha毎に229が送信されて
来る事などです。

VK_PROCESSKEY (E5) ですね。

詳しいことは知りませんけど、IMEが処理したキー入力をアプリケー
ションにリダイレクトする際に、何かしらの細工をしているのでしょう。

Post by unknown
何故か判らないけど、keychaｒでとkey_downで変換ウィンドウの
位置が1文字分12ポイントなら17ピクセル連れていることなどで。

IMR_COMPOSITIONWINDOW や IMC_SETCOMPOSITIONWINDOW
が処理されるタイミングを追いかけてみては?
WM_KEYDOWNからWM_CHARに至る過程で変換ウィンドウの位置を
調整しているのかもしれません。

Post by unknown
又、何故かＡｔｏｋでは変換ウィンドウでの字体が縦長（縦倍角のような）
字体になります。又文字がブルーになっています。

変換ウィンドウなどIMEの管理下にあるウィンドウのスタイルはIMEに
依存するのではないでしょうか?
ただ、できるだけ違和感のないようにアプリケーションに溶け込むため
にアプリケーションとの間で様々な情報を交換しているので、もしそこに
齟齬があると期待したような表示にはならないかもしれません。
IMR_COMPOSITIONFONT か IMC_SETCOMPOSITIONFONT 辺り
をチェックしてみては?

いずれにせよ、原則としてIMEは決められた仕様の範囲で動いている
のですから、まずはリファレンスをあたってみるのが近道かと。