表示文字列の最右下端のＸとＹ位置を知りたいのですが。
ポケットうえだ
これらをＩＭＭの変換ウインドウと重ね合わせています。
変換中の文字サイズと変換後の文字サイズはどちらも
34ポイントにしています。
見にくいので、変換ウインドウを確定後の位置に毎回
移動したいと考えています。
そこで実現するためには表示完了した文字の直後に
変換ウインドウを移動する必要があります。
TextOutで表示する際は開始位置のｘとｙを指定しますが、
表示完了して時点たとえば
「あいうえお」とすると「お」の右下端の位置が知りたい場合に
どうすれば良いでしょうか。一発で取り出すＡＰＩがあれば
助かるのですが。なければ表示文字列の長さを計算する
ことから始めなければなりませんか。
UETA, Shin-ichi
ポケットうえだ wrote:
> 「あいうえお」とすると「お」の右下端の位置が知りたい場合に
> どうすれば良いでしょうか。一発で取り出すＡＰＩがあれば
> 助かるのですが。なければ表示文字列の長さを計算する
> ことから始めなければなりませんか。
単純に考えると、状況に応じて
・GetTextExtentPoint32
・GetTabbedTextExtent
・DrawText(DT_CALCRECT)
―― のどれかを使って描画範囲を求めることになるのでは?
--
植田システム設計事務所
Ueta System Design Studio
http://www.usdesign.jp/
植田真一
mailto:ue...@usdesign.jp
ポケットうえだ
上田です。
ご示唆頂いた中から「GetTextExtentPoint32」を使って見ました。
この関数から横サイズは全角1文字で１６、縦サイズで１８と
与えられました。１文字増える度に横が＋１６されます。縦は
ずっと１８のままでした。これでこの関数からは文字数に応じて
横サイズが変わることが確認できました。
ところで横サイズの１６の意味ですが、色々と実測したり、
計算したりして次の通りの意味でないか結論になりました。
１６は文字ポイントサイズに関わらず一定で、１２ポイントでの
ピクセルの長さを表しているとなりました。
これで正しいでしょうか。（使用画面は１０２４×７６８）
１６＝１２×９６（dpi）／ ７２
> ・GetTextExtentPoint32
> ・GetTabbedTextExtent
> ・DrawText(DT_CALCRECT)
UETA, Shin-ichi
ポケットうえだ wrote:
> ところで横サイズの１６の意味ですが、色々と実測したり、
> 計算したりして次の通りの意味でないか結論になりました。
> １６は文字ポイントサイズに関わらず一定で、１２ポイントでの
> ピクセルの長さを表しているとなりました。
ん～、DCにアタッチされているフォントに合わせて計算結果は
変わってくるかと思うのですが、その辺りは間違いないですか?
12ptはデフォルトでアタッチされているフォントのサイズのよう
にも思えます。
また、プロポーショナルフォントだと必ずしも一定の幅では増え
ていかないかもしれませんし、全角と半角の混在も考慮しなけ
ればならないので、1文字につき n ピクセル増える ―― なんて
決め打ちはできないでしょうね。
# 固定ピッチのフォントしか使わないテキストエディタみたいな
# アプリケーションならともかく...。
ちなみに、ポイント数からピクセル数への変換については、
LOGFONT構造体のlfHeightの解説にある計算式（計算結果
の符号はlfHeight に固有の意味があるのでそれは除きます）
が参考になるはずです。
# 12pt * 96dpi / 72 がまさにそれです。
ポケットうえだ
変換ウィンドウについて、検証していくと色々と判ってきました。
12ポイントサイズの応じての実際のピクセル単位は
縦が18、横が16
ポイントサイズの比例させれば、実際のピクセル長になること
表示位置とは４ピクセル連れていること
横幅はスペースを考えて実際は+1、つまり12ポイントなら17で
あることなどです。
又日本語入力に入るとkey_downには1cha毎に229が送信されて
来る事などです。
何故か判らないけど、keychaｒでとkey_downで変換ウィンドウの
位置が1文字分12ポイントなら17ピクセル連れていることなどで。
又、何故かＡｔｏｋでは変換ウィンドウでの字体が縦長（縦倍角のような）
字体になります。又文字がブルーになっています。
最近の一太郎は知らないのでちょつとびっくりしています。
UETA, Shin-ichi
ポケットうえだ wrote:
> 横幅はスペースを考えて実際は+1、つまり12ポイントなら17で
> あることなどです。
GetTextMetrics で TEXTMETRIC を取り出せば正確な情報が
得られると思いますよ。
詳しくはこれ↓をご覧ください。
http://msdn.microsoft.com/en-us/library/dd144835(VS.85).aspx
ポケットうえだ wrote:
> 又日本語入力に入るとkey_downには1cha毎に229が送信されて
> 来る事などです。
VK_PROCESSKEY (E5) ですね。
詳しいことは知りませんけど、IMEが処理したキー入力をアプリケー
ションにリダイレクトする際に、何かしらの細工をしているのでしょう。
ポケットうえだ wrote:
> 何故か判らないけど、keychaｒでとkey_downで変換ウィンドウの
> 位置が1文字分12ポイントなら17ピクセル連れていることなどで。
IMR_COMPOSITIONWINDOW や IMC_SETCOMPOSITIONWINDOW
が処理されるタイミングを追いかけてみては?
WM_KEYDOWNからWM_CHARに至る過程で変換ウィンドウの位置を
調整しているのかもしれません。
ポケットうえだ wrote:
> 又、何故かＡｔｏｋでは変換ウィンドウでの字体が縦長（縦倍角のような）
> 字体になります。又文字がブルーになっています。
変換ウィンドウなどIMEの管理下にあるウィンドウのスタイルはIMEに
依存するのではないでしょうか?
ただ、できるだけ違和感のないようにアプリケーションに溶け込むため
にアプリケーションとの間で様々な情報を交換しているので、もしそこに
齟齬があると期待したような表示にはならないかもしれません。
IMR_COMPOSITIONFONT か IMC_SETCOMPOSITIONFONT 辺り
をチェックしてみては?
いずれにせよ、原則としてIMEは決められた仕様の範囲で動いている
のですから、まずはリファレンスをあたってみるのが近道かと。