Hi DPIサポートとベクターロゴを備えた純粋なWINAPI Webインストーラー

現在、これはおそらく純粋なWINAPIで記述されたアプリケーションの主要なアプリケーションの1つです。 純粋なWINAPIでいくつかの単純なウィンドウよりも深刻なものを書くことはもはや楽しいことではありませんが、小さなインストーラーが重要です。



2018年は年なので、アプリケーションだけを書くのはどういうわけかあまり良くありません。 時代のトレンドに合わせてみましょう-インストーラーはHi DPIモードをサポートします。 ラップトップでも、デスクトップはもちろんのこと、4Kスクリーンも珍しくありません。 さて、インストーラーはすぐに起動するはずのものなので、私たちにとって本当に難しくないことを節約します。 さて、追加のライブラリなしでベクターグラフィックスを使用するためにチートを試みましょう-美しいロゴも必要です！







まず、高DPIデスクトップアプリケーションの作成方法に関するMicrosoftの最新（今日）のガイドです。 これは、WindowsアプリケーションのさまざまなDPIのサポートモードの難易度を示しています。 そして、すでにいくつの異なる機能が追加されているのか... Windows 10より前は、システムはDPIに従ってフォントを描画することしかできませんでしたが、同時に、インデントやその他のサイズはひどく「フローティング」で、他はすべて引き伸ばされていました。 このモードは、XPスタイルのDPIスケーリングと呼ばれます。 Vistaからは、システムがアプリケーションをバッファーに引き込み、最終的な画像を引き伸ばしましたが、結果もまあまあで、すべてがぼやけていました。 Windows 8.1以降、システムはDPIの変更に関するメッセージをその場で送信し始めましたが、メインアプリケーションウィンドウのみに送信されました。 DPIの変更を確認するためにユーザーセッションを閉じる必要はありません。 そして、Windows 10でのみ、システムはGDI（テキストおよび共通コントロール）を介して行われたすべてを再描画することを学び、すぐにではなく、Creators Updateの後、Windows 10でもすべてを行うことはできません：







したがって、DPI対応アプリケーションを作成する場合は、ドキュメントに従ってUWPを実行する必要があります。このフレームワークのみがDPIをサポートし、すべてを行います。 それ以外はすべて、何らかの形での手動制御が必要になります。



実際、これは実際には必要ありません。すべてを自分で描きます。 最初に、現在のDPIを取得し、システムからのメッセージをリッスンします-DPIをオンザフライで変更します（システムがサポートしている場合）。 次に、必要に応じて単純にウィンドウ/コンポーネントを描画し、DPIを考慮して、プログラムの実行中にユーザーがDPIを変更するか、DPIが異なる別のモニターにウィンドウをドラッグする場合は更新します。 コモンコントロールを使用することはできません。Windows10 1703より前のDPIの変更に対応することはできません。ご自身で行ってください。



ラッパーはすべてのコンポーネント（ウィンドウとコントロール）向けに作成されているため、ウィンドウプロシージャを「C」スタイルで作成するのは好ましくありません。 ここでは、ゼロからでも多くの作業はありません（既にすべてを事前に知っている場合）。そして、すべてのWINAPIプログラマーは、ストレージに同じようなものを長く持っています。 必要なもの：

1. Windows向けの抽象的なもの（Windows）
2. コントロールの抽象的なもの
3. テキスト要素（テキストボックス）
4. ボタンテキストとエフェクト（ボタン）
5. 進捗インジケータ
6. リンク
7. 設定を選択するためのテキスト付きのフラグ（チェックボックス）
8. ベクトルのロゴのトリッキーな要素。
9. さて、プラスそれらの異なる組み合わせ

WINAPIでは、ウィンドウとコントロール（これもウィンドウです）の操作の理論全体を伝えることは適切ではありません。 つまり、次のようなものです。GUI要素が作成されると、システムはそのハンドル（HWND）を返し、作成された要素のデータを指します。 要素とウィンドウにはメインプロシージャがあります-要素への呼び出しを解析し、要素からの要求を実行します（または実行しません）。 要素は、メッセージ（メッセージ自体とその2つのパラメーター：wparamおよびlparam）を介してアクセスされます。 何かをやり直すために、メインプロシージャを独自に再定義し、必要なメッセージを処理し、メインプロシージャを制御して、さらに何かを分解する必要があることを通知するか、すでにすべてを行っています。 他のシステムでは、GUIはほぼ同じです-複雑なものはありません。



さて、あなたはWINAPIプログラマです。 ほぼ。



最終的に行うのはメインウィンドウです。ここでは、いくつかのボタンを押していくつかのオプションを選択できます。 [インストール]ボタンをクリックすると、背景がぼやけたファッショナブルな進行状況インジケーターが表示されます。これは、Windows XPから動作します。 ダイアログボックスを基礎としてみましょう-これが最も簡単な方法です。







では、順番に見てみましょう。HiDPIについてはどうでしょうか。 Windows自体は、アプリケーションマニフェストを使用して、アプリケーションからDPIサポート（dpi対応）を定義します。これは、しばらくの間実質的に必須でした。 たとえば、Windows c 8.1のDPIに加えて、GetVersion関数も変更されました -マニフェストでサポートするシステムが示されていない場合、GetVersionは6.2（Windows 8より古いすべてのシステムでWindows 8でアプリケーションが実行されているかのように）またはリストから最も適切なものを返します追加するシステム。 したがって、マニフェストは多くの理由で必要です。 マニフェストの例はここで見つけることができ 、すべての可能なマニフェストオプションはここにリストされています 。



アプリケーションには、DPIを操作するための4つのオプションがあります。

1. DPI Unaware - DPIについて何も知りません（すべてはシステムによって行われますが、どのように行われるか）
2. システムDPI認識 - システムDPIを取得し、最初にアプリケーションを初期化します（Widows Vista）
3. モニターごと -システムのDPIではなく、アプリケーションが表示されるモニターのDPIを取得します。 ユーザーが異なるDPIの異なるモニター間でアプリケーションをドラッグしたときにメッセージを処理しますが、それらはトップレベルウィンドウにのみ表示されます（Widows 8.1）
4. モニターごと（V2）はモニターごとと同じですが、システムはすべてのウィンドウにメッセージを送信します。 さらに、システム自体は、ウィンドウの非クライアント部分のサイズ、共通コントロール、およびCreateDialog（Creators Updateビルド1703以降のWindows 10）で作成されたダイアログボックスの初期サイズを調整します。

最後の3つのモードでは、システムは（ほとんど）アプリケーションから「手を離し」、何にも触れず、仮想化せずにすべての座標とサイズをピクセル単位で提供します。 もちろん、上記の点を除きます。 Per-Monitorモードは私たちにとって最適であり、Per-Monitor V2の機能は干渉するだけです。



しかし、これはもちろん問題がないわけではありません。 Visual Studioのデザイナーでダイアログボックスを作成するのが好きなので、深刻な問題が発生します。 マイクロソフト自体は、対話型アプリケーションを手動で作成し、すべての要素を手動でウィンドウに追加することを提供しています -申し訳ありませんが、これを購読していません。 問題は、リソース（ダイアログテンプレート）のダイアログボックスサイズがDLU（DIALOG UNITS）に保存されることです。 また、現在のDLU値は、システムのDPIに応じて変わります。 DPIとDIALOG UNITSが互いに重ねられていることがわかります。 さらに、DPIとは異なり、オンザフライで（DIALOG UNITS）は変更されず、DPIを変更した後は、新しいセッションでのみ機能します。 それだけでなく、 GetDialogBaseUnits（）関数を使用して変更をカウントしようとすると、サイズは変動します。 実際のウィンドウサイズの計算は、 このメッセージを間接的に確認するいくつかの他のパラメーターに依存していることがわかります 。 つまり、アプリケーションの開始時に初期の正しいサイズを示すことはできません。 ダイアログデザイナを拒否したくないので、ウィンドウの初期サイズとウィンドウ内の要素を常にあたかも96 DPIであるかのように示すコードが表示され、DPIに応じて変更します。 ダイアログとその要素のリソースについて説明する必要がありました。 さらに、ウィンドウ/要素のサイズはデフォルトでDLUで乗算され、初期化ウィンドウはこの形式に縮小されます。



しかし、今ではすべてが単純です-ウィンドウのサイズと開始時に要素を調整した後、デフォルトのDPI（96）を使用して、ウィンドウの現在のDPIのウィンドウサイズの初期化を行い、ウィンドウ内のすべての子に対しても行います。 これは1ステップで実行できますが、2つ残しました。 そして、そこで何が起こっているのかはまったく明確ではありません。



ただし、メッセージWM_DPICHANGEDがウィンドウに到着すると、最初のパラメーターは新しいDPIになり、2番目はシステムが送信するウィンドウの推奨サイズと位置になることを忘れてはなりません。 これを考慮に入れずに自分で考えてみると、異なるDPIのモニター間でウィンドウをドラッグすると、ウィンドウが画面の床に隠れます（実装方法によって異なります）。

つまり、ウィンドウ自体のサイズを処理する必要はありません。システムは希望のサイズを送信します。 ただし、子ウィンドウは処理する必要があります（モニターごとのモードバージョン1があります）。



アプリケーションは、単一のウィンドウと、さまざまな共通のプロパティおよびオプションを備えたInstallManagerとして実装されます（シングルトンを介して実装されます）。 したがって、私のプロジェクトでははるかに便利ですが、ここでも干渉しないようです。



プロジェクトファイルの詳細な説明。 フォルダ内のウィンドウのすべて：webinstaller \ windows \



抽象的で一般的なクラスのウィンドウ

class AbstractDialog
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本クラス-複数のウィンドウがある場合に主要な機能を簡単に手探りする

 class BaseDialog : public AbstractDialog
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OnEraseBackgroundに注意してください。ウィンドウのグラデーション背景の可能性がそこに実装されています。 これを行うには、WINAPI GradientFill関数を使用します。



どちらかといえば、webinstaller \ install \ installer_constants.hで背景を通常に変更することができます。GRADIENT_BG宣言を削除するだけです。



私たちの場合、特定のウィンドウがメインです

 class MainDialog : public BaseDialog
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さまざまな程度のユーティリティのあらゆる種類のユーティリティ

 namespace WindowsUtils
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、RectHolderは、RECT構造から継承し、WidthやHeightなどの追加メソッドをいくつか含んでいます。 そうでなければ、blablabla.bottom-blablabla.topなどを書くのは非常に退屈です。



そして、結果を丸めない置換MulDiv（MultiplyThenDivide）は、小さな値（フォントにとって重要）で不快なサイズのジャンプを回避できます。



はい、ところで、これはすべて、これよりもかなり複雑な生きているプロジェクトから部分的に引き裂かれています。だから私を責めないでください-あらゆる種類の奇妙なものが利用可能です。 削除されたものを置き換えるために、その場で終了することが必要な場合があり、非論理的に見えます。 最後に、これは例です。 ダウンロード、アンパック、インストールはスタブとして行われます-これらはすべてWinInet関数を介して非常に簡単に行われ、記事のメイントピックには実際には適用されません。



そして、コントロールについてはどうでしょうか... DPIサポートに関する限り、すべてがシンプルで、ウィンドウがそれを行います。 また、残りの実装もそれほど複雑ではありません。



すべてがフォルダ内にあります：webinstaller \ ui \



UI要素の基本クラス

 class BaseControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

静的な要素、まあ、ただのテキスト

 class StaticControl : public BaseControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

興味深いのは、ウィンドウを再描画せずに要素を再描画する必要があるかもしれないことと、グラデーションを使用した場合の背景です。最初のレンダリングで要素の下に背景を保存し、毎回描画する必要があります。 また、まだ少し欠陥があります。ウィンドウがクリアされていないときにこのバッファが読み取られることがあり、上部に再描画すると、テキストが少し太くなることがあります。 突然、あなたはどのように移動するかを見つけるでしょう:)



リンクするテキスト

 class LinkControl : public StaticControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テキストといくつかのリンク（ウィンドウの一番下の行）の両方を追加できるトリッキーな要素

 class CompositeLinkControl : public LinkControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーとプライバシーポリシーとの合意について書くのに便利になりました。 個別の要素として行うと、インデントと配置が乱れます。



進捗インジケータ

 class ProgressControl : public BaseControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データに応じて2色でストリップを描画する通常の基本要素。 プラスマーキーモード（ロシア語の正確な説明を一言で見つけるのは困難です）。 これは、操作がどのくらい続くかを正確に知らず、インジケーターの周りを円で巡る短いストリップを描くだけです。 これを行うには、パラメーター0、0でウィンドウからタイマーの要素関数を呼び出す必要があります。



四角ボタン

 class RectButtonControl : public LinkControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ボタンは条件付きで正方形です。ボタンの色を具体的に設定すると、背景ができ、背景の端が丸くぼやけます-もちろん、美しさのためです。

ボタンのテキストは影付きで描画できます。



ベクトルのロゴなどのトリッキーな要素

 class LayeredStaticControl : public StaticControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

遠くから始めましょう。 サイズは2つではなく2つ（100％、125％、150％、175％、200％...）になるため、すべての解像度の画像をストックするのは無駄に見えますが、同時にロゴは通常ベクターです。 しかし、WindowsはEMF以外の一般的なものをサポートしていません。これは基本的にEMF / EMF +のGDI / GDI +呼び出しログです。 このオプションは悪くありませんが、いくつかの制限がありますが、非常に複雑なことをする必要があり、必要な画像をEMF +でラップできる場合はそれだけです。 図面を回転させて、エッジを適切にぼかすと、いいかもしれません。 GDI + 1.1を使用するだけで、最小はWindows Vistaです（本質はMetafile.ConvertToEmfPlus関数にあります）。 通常のEMFはアンチエイリアスを行いません。



GDI +を使用しない場合、Windowsのベクターコンポーネントは1つしかありません。これはフォントレンダリングです。 また、1色で実行されるため、ロゴを色に分解する必要があります。



それがlayered_static_controlのすべてです。 いくつかの文字が取得され、目的の色で順番に描画されます。 実際、文字スタイルはすでにフォント内で複合されているため、ここでは特に新しいものはありません。 コンポーネントと色の内部で変更できないため、このメカニズムを使用できない場合を除きます。



たとえば、TwitterからSVGマウスを取り出し、色の数で4つの部分に分類し、OpenSansフォントを取得して、中括弧文字の代わりにそこに配置し、わずかに修正しました。 これらはすべて、便利なオープンソースエディタであるFontForgeで 30分で完了します。 同時に、ウィンドウに素敵なフォントが表示されます。







SVGをIllustratorにロードし、すでにパーツに含まれているSVGにアンロードしました。 FontForgeおよびFontForge自体にロードされ、輪郭が閉じられるように修正されました。 これを行うには、FontForgeで要素エラーチェックを呼び出します。要素->エラーチェック->輪郭->輪郭を開きます。 チェックした後、彼は目的のポイントを強調表示し、あなたはただつかみ、移動して同じ場所に置く必要があります-彼はこの回路を閉じます。



次に、2つの重要なステップがあります：文字を同じサイズ/メトリック（レイヤーに使用するもの）に設定し、フォント名（FontForgeのプロパティ）を変更することを忘れないでください。そうしないと、アプリケーションにすでにロードしようとすると、すでにインストールされていることがわかりますシステム内で使用されます（オリジナル）。



ちなみに、スペースを節約しているため、フォントから未使用の文字をすべて削除できます。すると、フォントは非常に小さくなります（ロシア語+英語の文字+数字と記号-29kb）。 注意すべき主なことは、フォント内の多くの文字が合成されていることです。 たとえば、文字thの一番上のバーはOpenSansフォントの最後にあり、別の要素として表示されます。



要素自体に、レイヤーとその色を追加します-すべてが単純です。



ロゴ/シンボルの一部はグラデーションで描画できます-これにはGDI +を使用する必要があり、グラデーションブラシがあります。 GDI +でStaticControlとLayeredStaticControlの新しい実装を作成するだけです。



ちなみに、ウィンドウを閉じるボタンはまだ文字Xと非常に似ていないため、（\の代わりに）フォントで個別に作成されます。



オプションと設定を選択するための要素（チェックボックス）

 class CompositeCheckboxControl : public CompositeLinkControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでも、ベクターなしでは実行できませんでしたが、どういうわけか、dawなどを描画する必要があります。 前に書いたように、Windows 10.1703だけが共通コントロールを再描画できます。 すべてがロゴにマウスを使用した例に似ています。フレーム、きれいな背景、フラグ自体が必要です。



機能の面で、プログラムに何かをインストールする場合（突然）、または特に重要なものに言及する場合は、別途契約書への参照が必要になります。 これは、ここでは別個の要素として提供されます。



InstallManagerで選択されたオプションのステータスを変更する選択要素-それ以外の場合、CompositeCheckboxControlを完全に継承します。

 class OptionCheckboxControl : public CompositeCheckboxControl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションマニフェスト

 webinstaller\installer\install.manifest
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の行に注意してください。

 <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、モニターモードごとにDPIをサポートすることをシステムに伝えるものです。 他のすべてのDPI オプションはここにリストされています 。



シングルトンマネージャー

 class InstallerManager
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さまざまなシステム機能（ラッパー）

 namespace SystemUtils
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リソースのうち、フォントとアイコンしかありません

 webinstaller\installer\resources\webinstaller.ttf webinstaller\installer\resources\webinstaller.ico
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、それは基本的にそれです。 すべてについて160kb（もちろん、ネットワークからダウンロードせずに、強制的に数kbです）。



WINAPIアプリケーションのDPIに関する結果：



すべてのウィンドウ要素を自分で描画しない場合は、Windows 10.1703以降でのみ、Windowsでのレンダリングに関するほとんどすべての問題をシフトできます。 この場合、ラスタグラフィックスの問題を解決する必要があるだけです。 アプリケーションマニフェストにgdiscalingという特別なオプションを追加し、trueに設定するだけで十分です。 それがどのように機能するかを詳細に説明します 。 もちろん、レンダリングにGDIを使用する場合、またはフレームワークでGDIを使用する場合。



ビットマップ画像のセットをアプリケーションに追加しない場合-より大きなサイズでそれを取得し、GDI +を介して目的の解像度に単純に縮小できます-そこそこの適切な補間アルゴリズムがあります。 Microsoft自身が彼に助言している 。



一般に、それは私たちが自分で行うか、システムを慈悲に任せるかのどちらかです。 さらに、MicrosoftはSpring Creators Updateで新しいオプションを準備しています -Windowsでアプリケーションのぼかしを修正できるようにするためです。 どのように機能するかはまだ明確ではありませんが、GDIスケーリングが強制的に含まれている可能性があります。



ああ、もちろんgithub上のアプリケーションのリポジトリ 。