INASOFT 管理人のひとこと


フリーソフトダウンロードサイト「INASOFT」の管理人 矢吹拓也 が日々の「ひとこと」を語るページです。
2021年1月1日より、旧ブログ(blog.inasoft.org)からお引越ししました。
・INASOFT Webサイト: https://www.inasoft.org/
・管理人のふたこと(長文記事/寄稿文): https://www.inasoft.org/talk/
2022年7月下旬より再び本業多忙化してきているため、更新頻度は落ちます。 [2022/7/24 19:32]

目次 | ←前へ / 2021-04-10 00:00 / 次へ→ / 最新へ⇒

■で。「.NET」のWindows Formsアプリケーションの高DPI対策はどうするのか?WPF化はちょっとなぁ…

2021年 4月10日(土) 0:00:00



RSSRSS配信中
https://www.inasoft.org/



先日、C++で作成したWindowsフォームアプリケーションで高DPI環境に対応するにはどうしたらよいかということを考え、NumLockLockや、マウスふるふるはこれで行きましょうマウスのお供もうまく行ったのでこれで行きましょう、となってきておりました。

で、どうしようか考え中なのが、.NET Frameworkで作られている「キーボードシミュレータ」「複数行置換」「CaptureSaveAs」はどうしようか?ということになります。

app.manifestに追加する方法だと、なんだかうまくいかないらしいことが分かっています。

ただ、こういうオールドタイプのアプリケーションへの互換的な機能に頼るよりも、元から C# や VB.NET で作られているんだったら、WPF (Windows Presentation Foundation) アプリとして作り変えることも、比較的近道になるんじゃないか?とも思ったり。

ただ、WPFアプリって、Windows Formsアプリから作り変えるには、かなり敷居の高い存在であることも確かです。

WPFアプリは、見た目とロジックの分離でプログラムの作りをキレイにするにはとても良いのですが、Windows Formsアプリは、密結合を許しているというか、だからこそ見た目をインタラクティブに変えられるというか。

つまり、.NET Frameworkで作られているから移行は簡単だろうというわけではなく、モノづくりに関するいろいろな考えを改めなければならなかったりして、同じC#/VB.NETでコーディングしているからといって、必ずしも簡単なわけではない、という感じだったりします。

というか、色々調べていたら、もはやWPFも時代遅れであり、新しいのはUWPというものであり、新しいスタイル(XAMLを使ったUIということ?)をWin32から使えるようにするためのProject Reunionが進行中という話もあって、慌ててWPFに対応する必要はもはや無さそうで。

となると、アプリのスタイルは、Windows Formsのままにしつつ、策を弄して、なるべくプログラミング量を少なくして、きれいな拡大ダイアログを作りたい。

一番簡単そうなのは、次の方法。

(1) app.manifest には、次のテキストを加え、OSバージョン番号の認識と「アプリケーション」方式の拡大が行われるようにする。(高DPIスケールによりフォントサイズが変わる)

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    </application>
  </compatibility>

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>

この時点で、ダイアログは次のように拡大されます。

■通常時
MS UI ゴシックのままの通常時

■125%拡大時
MS UI ゴシックのままの125%拡大時

(2) 実行環境がWindows 10かつ日本語環境ならダイアログ中の全コントロール/メニューストリップのフォントを「Yu Gothic UI, 9pt」にする。

  Form1_Load() に次の文を追加:

   if (System.Threading.Thread.CurrentThread.CurrentUICulture.Name.StartsWith("ja") && Environment.OSVersion.Version.Major >= 10)
   {
     Font f = new Font("Yu Gothic UI", 9);
     this.Font = f;
     menuStrip1.Font = f;
   }

この時点で、ダイアログは次のように拡大されます。

■通常時
Yu Gothic UIで通常時

■125%拡大時
Yu Gothic UIで125%拡大時

FormのプロパティのAutoScaleModeにより、拡大時の挙動が変わるっぽいので研究中。Noneにしておくとロクなことにならないことだけはわかった。

→【追記】AutoScaleMode=Dpiが良いそうです。

Word, Excel, PowerPointで使うときの游ゴシックはクソ(太さの設定が変)ですが、このYu Gothic UIはWindows 10(日本語)の標準フォントになっているだけあって、なかなか良い感じです。拡大時も自然な見た目になってくれます。

ちょっと注意が必要そうなのが、Yu Gothic UIは、MS UI Gothicよりも1行の高さが大きいようなので、2行以上のテキスト(Label)を表示するときに欠けが発生しやすそうで、少し高さに余裕を持った設計をする必要がありそうです。(もしかして2018年ごろに不思議に思っていたDFの設定ダイアログ問題って、これのせい?)

…と、この方法でうまくいくなら、逆に、C++で作っているWindowsフォームアプリケーションも、この方法の応用でうまく行ったりしないかな?とか思い直したりしています。ただ、Per Monitor(複数モニタで、モニタごとに拡大率を変えている場合)への対応を考えると、この方法に変えてしまうのはあまり得策ではない気もする…。



目次 | ←前へ / 2021-04-10 00:00 / 次へ→ / 最新へ⇒


目次の表示:


ブログではないので、コメント機能とトラックバック機能は提供していません。ご質問・ご意見等はメールフィードバックまたはTwitter等からお願いします。いただいたご質問・ご意見などは、この「管理人のひとこと」の記事に追加、あるいは新規の記事にする形で一部または全文をそのまま、あるいは加工させていただいた上で、ご紹介させていただく場合があります。
当サイトでは掲載内容による不具合等に関する責任を持ちません。また、内容の正確性についての保証もありませんので、情報をご利用の際は、利用者の自己責任で確認をお願いします。本ページは公開から1年半後の任意のタイミングで削除される予定です。


- 最近の更新 -



3110419 (+0342)[+0401]

Copyright© 2010-2023 INASOFT