私は静的テキストのウィドウを作成しています.96/120/180 DPIのすべてのもののために、レイアウト用ミニエンジンを作成する必要があります。静的サイズの測定方法は？ WINAPI
ダイアログはコードで作成され、スタティックはコードで作成され、フォントはコード内で作成されます。ほとんどの場合、.rcのリソースにはDPI関連の問題もあります。
すべての問題は、静的なテキストの長さを見つける方法がわかりません。私は静的コントロールの初期サイズを計算する必要がありますまた、私はフォント単位のサイズで異なる静的間のパディングを計算する必要がありますが、私は前の静的のサイズを知らないので、私は次の1。
最大の問題は
誰も...ので、私はそれが計算されますテキスト測定機能とカスタムフォント、イタリック、ボールド、オーバーサイズの補正を見つけることができない、静的なワードラップを行うということです任意のアイデアがありますか？
static control styles（ENDELLIPSIS、PATHELLIPSISとLEFTNOWORDWRAPが）そうDT_WORDBREAK|DT_CALCRECTでのDrawText呼び出しは、おそらくあなたが得ることができる限り近くなり、DrawTextフラグにマッピングするように見える...
私は説得力を考えることができません他のすべてのGUIクラスライブラリがそれを行う方法とは異なる方法でこれを行う理由です。 「デザイン」DPI設定とターゲットマシンのDPI設定の間でウィンドウサイズを調整するだけです。 DPIに依存しない定数を使用するのは、すべてがピクセルベースなので、MFCでは非常に面倒です。したがって、ワークステーションを共通の96 DPI設定に保ち、そこからターゲットマシン上にスケールアップします。 TrueTypeのヒントのために少し余裕を持たなければなりません。
稀な状況では、スケーリングされたテキストは切り捨てられます。テキストでスタティックを作成し、最小幅にサイズ変更し、コンパイルを実行します。すべては問題ありません。ダイアログユニットはデフォルトのフォントに関連しているので、アプリケーションは120/180 DPIでうまく見えるはずです。しかし、いくつかのプロファイルでは、テキストは切り詰められます。そして、言語に応じてテキストが伸びたり縮んだりする傾向があるローカリゼーションがあります。これはrcファイルの混乱です。 – Coder
そして、winapiのDLU /ピクセル間を安全に変換する方法がないので、ピクセルベースのレイアウトエンジンに切り替えることを本当に考えています。だから、私は少なくとも、そのような変わった説明のつかないDLUマージンと調整を最初からやっていないだろう。また、ユニットがアプリ全体で一定であれば、WM_SIZEのものもずっと簡単です。 – Coder
まあ、STATICは単純なケースです。また、エディットコントロール、コンボボックスなどを拡大する必要があります。なぜなら、テキストが切り詰められることがあるため、TrueTypeヒントの問題について言及しました。そして、はい、あなたはドイツ人にローカライズするための宇宙空間を残しています。 –
これをすべて行うフレームワークを使用してみませんか？あなたは車輪を再構築する必要はありません。 –
私はMFCの経験が豊富で、私のために何かを試してやるためのフレームワークを見たいとは決して思っていません。ほとんどのコードは、フレームワークに対する回避策となります。そして、WINAPIはDPIをあまり知られていません。もちろん、おそらく私はDoMagic（）関数が不足しているかもしれませんが、これまでのところ、ほとんどのフレームワークは価値があるよりも多くのトラブルを追加します。 – Coder
MFCがGUIフレームワークのアイデアであれば、より多くのものを得る必要があります！ –