長谷川 裕行 （はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。 |
今回から、業務用アプリケーションのデザインについて考えていきます。デザインと言っても単にフォームの見せ方だけではなく、アプリケーションの構造、データの受け渡し方法、メッセージの表示方法など、様々な要素が関係してきます。
最初は、ユーザーインターフェイスの要とも言えるフォームデザインについて、業務用アプリケーション特有の問題を考えることにしましょう。
このコラムのテーマは、WindowsでVisualBasic(VB)を使って業務用アプリケーションを作ることです。と言っても、単にVBとデータベースの扱い方を理解していればよいという訳ではありません。
- 様々な環境と様々なプログラム -
コンピュータのOSは何種類もあり、それぞれ似た部分もあればまったく異なる部分もあります。また、プログラミング言語にもたくさんの種類があり、文法も作法も異なります。
WindowsなどのGUI環境の場合は、厄介なことに同じプログラミング言語でもインターフェイスの異なる開発環境が存在します。
さらに作成するプログラムにも、システム・プログラム、アプリケーション・プログラムなどの種類があり、アプリケーション・プログラムの中にも、ワープロなどの汎用アプリケーション、ゲーム、専用アプリケーションなどの種類があります。
業務用アプリケーションは、いわゆる専用アプリケーションに属します。
- 環境と目的の違いを知る -
巷に溢れるVBプログラミングの情報の中には、本コラムなどより遥かに詳細で役に立つものが多数あります。ただ、それらがすべて「VBで業務用のWindowsアプリケーションを作る」ために必要不可欠な情報であるとは限りません。目的に沿った情報を入手し、役立てていく必要があります。
「VBで業務用のWindowsアプリケーションを作る」という作業が、他のOSや他の開発環境で他の種類のプログラムを作るのとどう違うのか、また、VBで他の種類の(業務用ではない)アプリケーションを作るのとどう違うのか、知っておくことは重要です。OS、開発環境、目的による作法や基本的な考え方の違いを考えてみましょう。
Windowsは非常に便利なOSですが、汎用的過ぎるため(それが長所ともなっているのですが)業務用アプリケーションの実行環境としては不便な部分もあります。
- WindowsとGUI環境 -
Windows以外のOSと言えば、MacOSやLinuxなどのパソコン用OSを思い浮かべる人も多いでしょう。しかし、コンピュータはパソコンだけではありません。当然OSにも、Linuxのベースとなったワークステーションやミニコンピュータ用のUNIX、たくさんの端末機からの入力を一括処理する汎用機のOS、汎用機の端末も兼ね業務処理向けに特化されたオフィスコンピュータ(オフコン)用のOSなど、たくさんの種類があります。
中でも、業務処理プログラムの実行環境としては、汎用機やオフコンのOSが先達と言えます。現在でも、データベースを利用した業務用プログラムが多数稼働しています。
汎用機やオフコンのOSとWindowsの最大の違いは、GUIです。マウスを使ってアイコンやウィンドウを操作するという直感的なインタフェースでは、コンピュータに対してユーザーが「命令を与える」「指示を出す」という感覚は薄くなっています。
- 自由度が邪魔になることもある -
GUIを持つOSには、Windowsの他にWindowsの先輩とも言えるMacOSや、UNIXのX Windowシステムがあります。
X Windowシステムは、実行環境としては特殊な部類に入ります。UNIXも、基本はキーボードからのコマンド入力によるコンソール操作であり、X
Windowは一種の付加機能です。統合デスクトップ環境と呼ばれるGNOMEやKDEの登場で、UNIXのOSとしての位置付けも多少変わってはきていますが、コンソールという基本的な構造は変わっていません。
例えば、業務処理専用機として稼働するオフコンや汎用機の端末では、グラフィックスを使ってウィンドウをオープンしたり、アプリケーションを切り替えたりする必要はありません。そのような自由度は、かえって邪魔になります。
- 余計な操作はできない方がよい -
WindowsやMacOSは、パソコンが様々なユーザーに様々な状況下で使われることを想定して設計されています。インターネットも文書作成も、集計表の作成もデータ分析も、画像処理も作曲も、ゲームに占いまで…何でもござれの実行環境なのです。
目的によるインターフェイスの違いは非常に重要です。WindowsやMacOSで文書作成だけをする人、メール交換だけをする人、作曲だけをする人もたくさんいます。コンピュータから見れば限りなくオールマイティに近いのですが、一人のユーザーから見れば「単能機」であることも多いものです。
業務用のアプリケーションも単機能であり、多くの場合ほぼ専用として常時実行されることになります。そのため、Windowsのような自由度は特に必要ではありません。Windowsの自由な環境を、敢えて不自由にする必要も出てきます。
何でもできることと、できることをすべてしなければならないということとは、実は何の関係もないのだということを知っておいてください。
VBは特殊な開発環境で、機能が制限されているため使いにくいと言われることがあります。が、それは決して欠点ではありません。業務用アプリケーションの開発環境としては、非常によくできています。
- VBは特殊な環境? -
VBのインターフェイス、基本操作、Windowsプログラミングの作り方などについては、過去に本コラムでも取り上げてきました。これらについては、既にご存じのことでしょう。
VBはかなり特別な開発環境であるかのような印象を、抱いている人も多いかと思います。確かに、フォームをデザインし、各コントロールがアクセスされたときの振る舞いをコーディングしていくという作法は、一種独特のようなイメージがあります。しかし、この作法が独特に見えるのは、WindowsというGUI-OS上の開発環境であるためであって、プログラミング言語の構造としては極めて一般的なものなのです。
- それまでの開発環境とVB -
VBの特殊性は、特に旧来のC言語やC++といった「難しい言語」の開発を知っている人たちが語ったことです(その中には筆者も含まれます。すみません)。UNIXやDOSのC言語、アセンブリ言語からC++へと渡り歩いてきた者にとって、Windows版のVBは衝撃的で、その着想の斬新さに感心しました。
しかし、それはあくまでWindowsという実行環境の中で、これまでの「文字によるコーディング中心のプログラミング」という常識をくつがえした点に対しての驚きであって、OSがハードウェアの、言語構造がOSの内部を覆い隠しているという形態は、それまでのOSと開発環境の関係とまったく変わっていません。
むしろ、OSの提供する基本機能を直に使わなければならなかった、Windowsの初期のプログラミング作法の方が特殊だったのです。
- 目的に合った開発環境を選ぶ -
汎用機やオフコンのFORTRAN、COBOLといったプログラミング言語では、OSの持つ基本機能はその言語構造によって隠ぺいされています。そのことによって、プログラマーはハードウェアやOSの違いを意識することなく、アプリケーションの開発に取り組めるようになります。それが、高級言語の正しい姿です。
ときどき、VBを極めるにはC言語やC++を理解する方がよいという意見を聞きますが、それは、そう言っている人がC言語やC++からVBへと移行してきたためであって、これからVBを学ぶ人が、敢えて他の言語を学ぶ必要はありません。
例えば、VBでWindowsの基本機能を存分に利用するためにAPI関数を呼び出すという手法は、少なくとも業務アプリケーション開発のレベルでは余程のことがない限り使用しません(不要と言ってもよいでしょう)。どうしてもそれを使用せざるを得ないなら、CやC++など他の言語を利用する方が簡単で、しかも効率的です。
開発環境の基本機能でできる範囲のことを組み合わせ、目的の処理を作り上げるのが最も簡単で、プログラマーの負担も軽くなります。要は、目的に応じた開発環境を選ぶことです。
VBは、システム・プログラムや高速なゲームの開発を目指さない限り、ほとんどの目的に対応できます。つまり普通の業務アプリケーションなら、VBで十分にカバーできるということです。
業務用アプリケーションは、「伝票を印刷する」「販売記録を蓄える」といった具体的で明確な目的を持つプログラムです。
ワープロや表計算などの汎用アプリケーションでは、ユーザーがどんな文章を入力するか、どんな計算式を設定するかが予測できません。そのため、搭載している機能は幅広く、様々な操作を受け入れるように設計されています。しかし、限定された目的を持つ業務アプリケーションでは、受け入れるユーザーの操作も限定されてきます。
例えば、日付を入力するテキストボックスには、氏名や電話番号を入力するための機能は不要です。逆に、日付しか入力できないような配慮がなされている方が、ユーザーは扱いやすくなります。
業務アプリケーションでは、余分な機能を排除し、機能を限定してしまう方が親切な設計となります。業務アプリケーションのユーザーインターフェイスは、必要なデータを得、ユーザーの目指す機能を簡単に実行できるようにするため、極めて抑制的な性質を持っています。
これは、作曲用のプログラムが作曲のための機能しか持っていないことや、フォトレタッチソフトが画像処理機能に特化されていることを考えればお分かりいただけるでしょう。業務用アプリケーションは、機能をさらに限定的にしたものだと言えます。
Windows上でVBとデータベースを使って業務用アプリケーションを作る――という場合、「OSがGUIであること」「開発環境がVBであること」「目的が限定されたものであること」の3点を意識しておく必要があります。
これらを踏まえた上で、VBによる業務アプリケーションのためのユーザーインターフェイスについて考えていきましょう。
- メニュー画面から始まる -
既にご存じのように、VBではまずフォームのデザインから入ります。このとき、最初に表示されるフォームはメニュー画面となります。ここで言うメニューとは、「ファイル(F)」などのWindowsのメニューバーではなく、コマンドボタンを並べた処理選択用の画面です。
画面1:コマンドボタンを配したメニューフォーム
業務処理では、1つの大きな処理が複数の小さな処理に分かれていることが多くなります。そのため、最初に表示される画面は、それら小さな処理を選択するメニューとなる場合が多いのです。従って、アプリケーションはある業務に関連する小さなプログラムを集め1つのメニュー画面から、それら個々の処理へと分岐させる構造を持つことになります。
- コマンドボタンでフォームを切り替える -
画面に配されたコマンドボタンには「入金」「伝票発行」「日次処理」「月次処理」といった項目名が表示され、それらをクリックすると目的の処理を行なうフォームがオープンします。
例えば、コマンドボタンcmd入金がクリックされたときに、フォームfrm入金がオープンする――という形なら、以下のようなプロシージャを作ることになるでしょう。
Private Sub cmd入金_Click()
Me.Visible = False
frm入金.Show
End Sub |
- 処理用フォームからメニューに戻る -
オープンしたフォームfrm入金には、その処理で必要なコントロールに加えて、「処理を終えて元のフォーム(メニュー画面)に戻る」ボタンを設けておきます。このボタンがcmdCloseで、元のメニュー用フォームがfrmMainMenuなら、コマンドボタンがクリックされたときの処理は以下のようになるでしょう。 |
|
Private Sub cmdClose_Click()
Me.Visible = False
frmMainMenu.Visible = True
End Sub |
メニュー用のフォームと、そこからコマンドボタンのクリックによって選択される処理との間は、上記のようなプロシージャで結ばれることになります。
図1:メニュー用のフォームと各処理用フォームとの関係
ウィンドウを自由にデザインできるVBでは、メニュー画面を単なる処理分岐用パネルにとどめておく必要はありません。メニューに他の機能を割り付けることも可能です。
- メニューに基本処理を組み込む -
業務処理の場合、上述したような個々の処理に先立って処理年月日、処理担当者などの情報を設定しておく必要がある場合があります。
汎用機やオフコンで用いられていたプログラムでは、このようなとき
1.日付と担当者の入力
2.入金処理
3.出金処理
:
9.終了
などとメニュー項目が表示され、まず1番を選択して日付と担当者を入力してから次の処理を選択する…といった手順を採るよう指定されたりしていました。
そのためオフコンや汎用機でCOBOLを使っていた人の中には、Windowsでもメニュー画面に「日付入力」「担当者入力」といったコマンドボタンを配してしまう人がときどきいます。が、このようなデザインはユーザーに余計な処理選択の手間をかけるため、感心しません。
メニュー用とは言っても通常のフォームなのですから、テキストボックスやオプションボタンなどコマンドボタン以外のコントロールも自由に配置できます。メニュー画面に日付や氏名の入力欄を設ければよいのです。
画面2:メニュー画面で日付と担当者の入力を行わせる
- データチェック機能を付ける -
この場合、日付と担当者が入力されない限り、コマンドボタンから処理を選択できないようにした方が安全です。そのためには、日付入力用のテキストボックスや担当者選択用のコンボボックスが操作されたときに「正しいデータが入力されているか」を調べて
正しいデータが入力されていれば
→コマンドボタンを有効に設定する
正しいデータでなければ
→コマンドボタンを無効にする
といった処理を作っておきます。
- コマンドボタンの有効/無効を切り替える -
日付入力用のテキストボックスがtxtDateなら、その内容が変更されたときにTextプロパティの値を調べ、正しい日付データならコマンドボタンのEnabledプロパティにTrue、そうでなければFalseを代入するだけです。
ここでは、まずコマンドボタンの有効/無効化を設定するプロシージャを下請け処理として作っておきます。
リスト1:コマンドボタンの有効/無効を切り替えるプロシージャ
Private Sub EnableButtons(sw As Boolean)
cmd入金.Enabled = sw
cmd出金.Enabled = sw
End Sub |
- 日付入力のチェック処理 -
テキストボックスでは、Form_Loadプロシージャで予め今日の日付を設定しておいた方が親切でしょう。また、初期状態ではコマンドボタンを無効にしておきます。
Private Sub Form_Load()
: ' 日付の設定
txtDate.Text = Format(Date, "yyyy-mm-dd")
: ' コマンドボタンを無効化
EnableButtons(False)
:
End Sub |
この状態でテキストボックスの中が書き換えられたら、以下の処理を実行するようにします。
リスト2:日付入力が正しいかチェックするプロシージャ
Private Sub txtDate_Change()
If IsDate(txtDate.Text) = True Then
EnableButtons(True)
Else
EnableButtons(False)
End If
End Sub |
- 担当者入力のチェック処理 -
担当者の選択はコンボボックスcmbUserで行うとします。コンボボックスの場合はChangeイベントの他にClickイベントでも対処できます。ただ、コンボボックスのChangeやClickイベントは「リストに対する操作」に対して発生するため、リストをオープンしないで[Delete]キーで文字列を削除したり、キーボードから直接文字列を入力した場合には、チェック機能が働かなくなります。
これを避けて、キーボードからの入力もチェックするようにしたければ、フォーカスを失ったときに機能するLostFocusイベントに設定する必要があります。LostFocusイベントは「他のコントロールを選択する直前」に発生するため、「選択してすぐにコマンドボタンの有効/無効を設定する」ことはできなくなりますが、[Tab]キーを押すなどしてコンボボックスからフォーカスが離れる直前に有効/無効が設定されるため、不自然ではありません。
リスト3:担当者の選択が正しいかチェックするプロシージャ
Private Sub cmbUser_LostFocus()
If cmbUser.Text <> "Nobody" _
And cmbUser.Text <> "" Then
EnableButtons(True)
Else
EnableButtons(False)
End If
End Sub |
画面3:日付や氏名が正しくなければコマンドボタンをクリックできない
ここまでに紹介した処理は、サンプルプログラムとしてプロジェクトとexeファイルを用意してあります。ダウンロードして、動作とソースコードを確認してください。
但し、実際に機能するのは「処理日付」のテキストボックス、「担当者」のコンボボックス、「振替伝票」「閉じる」のコマンドボタンだけです。その他のコマンドボタンは、クリックするとメッセージボックスを表示します。
なお、サンプルではコマンドボタンをコントロール配列とし、For Nextループで操作できるようにしてあります。
業務処理用のアプリケーションは、必要なときにすぐ実行できるよう、多くの場合朝から晩まで一日中起動しておきます。アプリケーションの内容や規模にもよりますが、実質的にコンピュータはその業務の専用機という形になることが多いでしょう。
そのような場合には、フォームのデザインに工夫を凝らす必要があります。
- 業務処理向けのフォームデザインを -
コンピュータを完全に業務処理専用とするなら、他のアプリケーションを実行できないようにしてしまうことも必要です。最も手軽な方法は、ウィンドウを画面いっぱいに広げウィンドウサイズを変更できないようにしておくことです。
他のアプリケーションも実行させたい場合でも、業務処理のウィンドウが常に画面中央に表示されるようにしておくとよいでしょう。特に、コンピュータに不慣れな人が扱う場合は、目的のウィンドウが他のウィンドウの下に隠れたり、最小化されてタスクバーに表示されただけでも、パニックになってしまうものです。できるだけ、そういった不用意な操作を受け付けないようにしておきましょう。
以下に、フォームデザインに必要なプロパティを掲げておきます。
- サイズ設定 -
最大化(フルスクリーン)とするには、フォームのMaximizedプロパティをTrueにしておきます。最大化させない場合は、ScaleMode、ScaleHeight、ScaleWidthの各プロパティをForm_Loadプロシージャで設定しておくのがよいでしょう。
ScaleMode
| |
フォームのサイズ設定に用いる単位を、以下の表に示す記号定数で指定します。 |
表1:ScaleModeプロパティに設定する値
| 記号定数 |
値 |
意味 |
| VbTwips |
1 |
twip(既定値) |
| VbPoints |
2 |
ポイント |
| VbPixels |
3 |
ピクセル
(画面またはプリンタの解像度の最小単位) |
| VbCharacters |
4 |
キャラクタ
(水平 = 1 単位あたり 120 twip、垂直 = 1 単位あたり 240 twip) |
| VbInches |
5 |
インチ |
| VbMillimeters |
6 |
ミリメートル |
| VbCentimeters |
7 |
センチメートル |
| VbUser |
0 |
ユーザー独自の単位 |
ScaleModeプロパティは標準ではtwipとなっていますが、画面に表示されるだけのフォームでは、ピクセルで指定した方が便利です。プロパティウィンドウでは、リストから"3
- ピクセル"を選択するだけです。
ScaleHeight
| |
フォームの高さを指定します。ScaleModeで設定した単位が適用されます。 |
ScaleWidth
| |
フォームの幅を指定します。ScaleModeで設定した単位が適用されます。 |
ScaleModeプロパティでtwip以外の単位を用いるよう設定した場合は、HeightとWidthプロパティではなくScaleHeight、ScaleWidthプロパティでフォームのサイズを指定します。
ウィンドウのサイズはコードで設定する他に、フォームウィンドウでドラッグして大きさを調整することもできます。プロパティウィンドウでScaleHeight、ScaleWidthプロパティに直接値を設定してもフォームのサイズは変わらず、ScaleModeプロパティが"0
- ユーザー"に設定し直されてしまいます。
- サイズの固定 -
通常、アプリケーションのウィンドウはフレームのドラッグによってサイズを変更できますが、業務用のアプリケーションではウィンドウ内に表示するべき情報は予め決まっていることがほとんどなので、サイズを変更できないようにしておいた方がよいでしょう。
ユーザーが間違ってサイズを変更すると、必要な情報が隠れて見えなくなることがあります。
ウィンドウのサイズを固定するには、BorderStyleプロパティを"1- 固定(実線)"または"3 - 固定ダイアログ"に設定します。BorderStyleプロパティはコードよりプロパティウィンドウで設定する方が手軽です。
- 表示位置の固定 -
フルスクリーン表示しない場合は、フォームを画面の中央に表示し、ウィンドウを移動できないようにするのがよいでしょう。
起動時のウィンドウの表示位置は、StartupPositionプロパティで設定します。"2 - 画面の中央"にしておけば、画面解像度にかかわらず常に画面の中央に表示されます。
ウィンドウを移動できなくするには、MovableプロパティをFalseにします。プロパティウィンドウで設定しておくとよいでしょう。
StartupPositionプロパティは実行時には設定できないので、プロパティウィンドウで設定するしかありません。コードでStartupPositionプロパティに値を代入しようとすると、実行時にエラーとなります。
 VBプロジェクトファイルのダウンロード
(LZH形式 8.56KB) |
