CodeZine(コードジン)

特集ページ一覧

マルチ解像度対応アプリ作成の近道
「PlusPak for Windows Forms 7.0J」の魅力に迫る!

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2013/05/30 16:00

 業務システムで使われるパソコンといえば、1024×768や1280×1024などの4:3スクリーンが中心でしたが、最近は1366×768をはじめとするワイドスクリーンが主流になっています。そのため一括切り替えを行っていない職場では、複数の解像度が混在している状況になります。また、液晶画面が主流になったことで、液晶画面が想定している解像度以外に設定すると、画質が悪くなってしまいます。にもかかわらず、業務アプリでは全画面表示が得意なSIerが多かったのか、画面デザインが解像度固定であったり、そうでなくても構築当時の画面サイズそのままに高解像度化が進んだためピクセル密度が高くなり、画面上の構成要素サイズが小さくなってしまったりと目に優しくない弊害が生じています。

 また、このような解像度対応はデザイン面にもさまざまな工夫が必要とされています。さらに、画面単位ではなく画面上のコントロール単位での対応が必要になるため費用も高くなりがちです。効果も「画面が見やすくなります」というものであるため、現場には切実でも決裁権のある人に響きづらいので、なかなか予算化されないといった問題もあります。

 つまり、効率的にマルチ解像度対応を行い、現場にも会社のお財布にも優しい対応を実現できるPlusPak for Windows Forms 7.0Jの重要度は以前にも増して大きくなってきています。そこで今回は、マルチ解像度、それも縦横比(アスペクト比)が変わるようなマルチ解像度でのPlusPakの活かし方にスポットライトを当てて、その実力を探ってみましょう。

マルチ解像度対応の問題点

 それでは複数の解像度が混在するマルチ解像度環境で、業務アプリが遭遇しそうな問題点を再確認してみましょう。

 例えば、2009年くらいに導入したPCと今年導入したPCが混在しているとします。2009年と2013年の日本での解像度の傾向をStatCounterで調べてみると、2009年は圧倒的に1024×768ですが2013年は1366×768や1920×1080の傾向が強いようです。

図1 画面解像度の推移
図1 画面解像度の推移

液晶サイズの違い

 具体的にイメージしやすいように、2009年に使用しているPCと2012年に使用しているPCのスペックを定義してみましょう。

表1 解像度、画面サイズと実表示サイズの違い
  2009年仕様 2013年仕様
CPU Core 2 Duo T5500 Core i5-2520M
メモリ 2G 4G
液晶 15.4型(XGA:1024×768) 15.6型(Full HD:1920×1080)
液晶サイズ 31.3×23.5cm 34.5cm×19.4cm
1024×768サイズ 31.3×23.5cm 18.4cm×13.8cm

 今回は、液晶15インチモデルという点は同じですが、2009年は4:3のXGAであり2013年はいわゆるワイドモデルである16:9のFull HDを想定しています。注目したいのは対角線の長さであるインチ表記は変わりませんが、縦横比が変わっているので、液晶縦サイズは23.5cmから19.4cmへ4.1cmも小さくなっている点です。

 これは決して差が大きくなるようにと意図的に選んだものではありません。2013年時点で型落ちでない限りは4:3液晶の法人向けノートPCを入手することが困難であり、コストパフォーマンスの良いバリューモデルを選んだとしても、1366×768なのか1920×1080なのかの差はあるかもしれませんが、16:9モデルが大半なのです。よって、この液晶の物理縦サイズが小さくなってしまうのは、いろいろな現場で遭遇していることだと推測できます。

図2 縦横比による液晶物理サイズの違い
図2 縦横比による液晶物理サイズの違い

 もし液晶の物理縦サイズを16:9でも23.5cmほしい時は18.8インチ、つまり19インチモデルが必要になります。その場合、横方向は41.6cmにもなってしまうため、4:3の15.4インチモデルと比較すると、実に10cmも横長の液晶が必要になります。

アプリ画面表示サイズの違い

 実際にアプリ画面を表示したときの物理サイズは、液晶物理サイズにさらに解像度が加味されます。

 1024×768で表示していた時の縦横サイズは、2009年想定であれば全画面相当なので31.3cm×23.5cmになります。一方、2013年想定であれば1027×768より高解像度になっているため、全画面ではなく画面の一部に18.4cm×13.8cmの大きさで表示されることになります。

 実に元々の大きさの60%くらいに縮小表示されてしまうわけです。

図3 ワイド化+高解像度化によるアプリ画面サイズの変化
図3 ワイド化+高解像度化によるアプリ画面サイズの変化

 これでは表示されている文字が小さすぎて、読めない可能性も大きくなります。

PlusPakがないときの対応

画面解像度の変更

 最初の対応案として、新PCの画面解像度を1024×768にしてみましょう。

 画面解像度を1024×768にすると、アプリ画面サイズは1024×768のままで全画面表示ができますが、縦横比の関係から液晶に何も表示できない黒い部分が左右にできてしまいます。

図4 画面解像度の変更
図4 画面解像度の変更

 この対策によって、なにも対策をしなかった時と比較すると、アプリ画面サイズの実サイズ変化はかなり少なくなっています。この程度であれば、文字の大きさの変化は耐えられる範囲かもしれません。

 しかし、この方法には1つ大きな問題があります。せっかくFull HDが表示できる新PCなのに、以前と同じ解像度にしてしまっては、一度に表示できるExcelシートのエリアも広くならず、作成した業務アプリの制限により高解像度の恩恵を受けることができません。

アプリ画面サイズを変更する

 次の対策案としては、画面解像度を変えるのではなく、アプリ画面サイズを変更する方法を考えてみましょう。

 実装方法は画面のLoadイベントの中でFormオブジェクトのWidthとHeight、各コントロールのTop、Left、Width、Heightのプロパティ値をすべて1.40625倍するロジックになります。各プロパティ値がInteger型なのに乗数が小数点数なので、計算後の値をInteger型に変換するところでどうしても値の切り捨てが発生し、多少のゆがみが生じる可能性があります。

図5 アプリ画面サイズの拡大
図5 アプリ画面サイズの拡大

 それよりも問題なのは、この対応のためにLoadイベントの中で記述しなければならないロジックがかなりの量になるという点です。ロジック記述工程、そしてテスト工程に必要な工数は少なくはありません。

 そこでPlusPak for Windows Forms 7.0Jの登場です。

PlusPakによるマルチ解像度対応

 PlusPakの機能をサンプルで確認するにあたり、確認がしやすいように画面サイズを縦横半分の大きさで想定して比較します。つまり、アプリ画面サイズ512×384のアプリを作成し、画面解像度512×384と画面解像度960×540の液晶を想定して比較できるようにすれば、手元の環境が1024×768の環境でも確認できるわけです。

図6 サンプルアプリ(CZ1304Full)
図6 サンプルアプリ(CZ1304Full)

 今回のサンプルでは512×384(旧PCの1024×768相当)のアプリ画面サイズで起動し[保存]ボタンをクリックすると960×540(新PCの1920×1080相当)にアプリ画面サイズが変化します。このサンプルを動作させてから画面スナップショットを取得し、4:3で15.4インチと16:9で15.6インチの液晶物理サイズ合わせをしたのが次の図です。

図7 全画面表示時の見え方の違い
図7 全画面表示時の見え方の違い

 DockプロパティやAnchorプロパティを使ってフォームの四辺に沿って移動しているコントロールもあります。しかし基本的には左上固定であり、高解像度で全面表示すると右や下方向に余白が広がってしまうのが一般的でしょう。

PlusPakを活用する

 PlusPakを使うために、まずはツールボックスにPlusPakのコンポーネントを追加します。今回は画面リサイズを行いたいので、GrapeCity.Win.PlusPak.v70アセンブリのGrapCity.Win.Components名前空間にある、GcResizeコンポーネントが対象となるコンポーネントになります。

 GcResizeコンポーネントを使うと、フォームのリサイズにあわせてレイアウトを維持したままフォーム内のコントロールを拡大/縮小することができます。

図8 ツールボックスへの追加
図8 ツールボックスへの追加

 追加が終わったら、次にツールボックスからWindowsフォームにドラッグ&ドロップしてみましょう。正しく操作できていれば、フォームデザイナのコンポーネントトレイにGcResizeコンポーネントが配置されるはずです。

図9 GcResizeコンポーネントの配置
図9 GcResizeコンポーネントの配置

 ではこの状態で、新PCの1920×1080相当にしてみましょう。[保存]ボタンをクリックして960×540にして画面スナップショットを取得して比較した結果は次のようになります。

図10 全画面表示時の見え方の違い(Resize利用)
図10 全画面表示時の見え方の違い(Resize利用)

 縦横比が4:3と16:9で異なるため、右辺のツリービューとの間に空きが生じてしまいますが、その他のコントロールの大きさや間隔、文字の大きさなどのバランスはかなり旧PCと近いイメージに仕上がっています。

 コンポーネントを貼っただけでこれだけのことができてしまうとすれば、マルチ解像度対応する場合のロジック記述工程は限りなく圧縮できるはずです。

高解像度化を積極的に利用する調整

 しかし、これだけ簡単に対応できてしまうと少々欲が出てきます。一律に拡大するだけではなく、高解像度化された分だけ情報量を増やした方がよいケースもあります。例えば、ツリービュー自体の領域は拡大しても、フォントは大きくせずにデータ表示量を増やしたいという要望があるかもしれません。特に顕著なのは旧PCの画面サイズでは横が収まらずに横スクロールが必要だった一覧表が、領域のみ拡大することでスクロールが要らなくなるということもあるかもしれません。

 このような要望もGcResizeコンポーネントは柔軟に対応できます。

図11 GcResizeコンポーネントによるプロパティ拡張
図11 GcResizeコンポーネントによるプロパティ拡張

 GcResizeコンポーネントを張り付けたWindowsフォームにあるコントロールには、AllowResizeプロパティとResizeModeプロパティが自動追加されます。

 AllowResiezプロパティは、GcResizeコンポーネントによるリサイズをするかどうかでデフォルトのTrueであればリサイズし、Falseに設定することでリサイズされなくなります。

 ResizeModeプロパティはリサイズ時の方法で、デフォルトのLayoutAndFontをLayoutに変更すると、次のように領域だけ拡大してフォントサイズは大きくしない動作をしてくれます。

図12 TreeViewのフォントサイズのみ拡大しない実行例
図12 TreeViewのフォントサイズのみ拡大しない実行例

リサイズポリシーについて

 GcResizeコンポーネントを使用するとフォームのリサイズにあわせて、フォーム内のコントロールのリサイズを行うことができますが、一部のコントロールはGcResizeコンポーネントでは対応できない問題点があります。

 GcResizeコンポーネントが提供するリサイズ機能だけでは対応できない個々のコントロールの問題点は、リサイズポリシーを使用して補正することで、適切にリサイズすることができます。

まとめ

 コントロール数が多いといった理由で、アプリ画面サイズのリサイズができていないシステムもあることでしょう。しかし、高解像度対応も現実味を帯びてくる手軽さだということが分かっていただけたのではないかと思います。

 さらにPlusPakのGcResizeコンポーネントを使えば、画面単位に最短時間でリサイズ対応を行うことができるだけではなく、ResizeModeプロパティやリサイズポリシー、そして最終的にはカスタムリサイズポリシーによりきめ細かなリサイズ制御が実現できます。

 既存資産を生かし、高解像液晶のポテンシャルも生かしたアプリ改修をPlusPak前提で検討してみてはいかがでしょうか。

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 初音玲(ハツネアキラ)

     国内SIerのSEでパッケージ製品開発を主に行っており、最近は、空間認識や音声認識などを応用した製品を手掛けています。  個人的には、仕事の内容をさらに拡張したHoloLensなどのMRを中心に活動しています。  Microsoft MVP for Windows Development...

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5