長谷川 裕行
（はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。 |
Visual Basic(以下「VB」)が登場した当初、Windowsはまだ3.1でRADツール※１という言葉も登場していませんでした。その頃VBを手にした人たちの中には、結局使いこなせずに諦めてしまった人が大勢います。
プログラミングはワープロや表計算ほど簡単ではないので、もともと途中で挫折する人が多いのはある意味で仕方ないことです。特にアマチュアプログラマーが膨大な数にのぼり、大量の開発ツールが流通している日本では、その裏で使いこなせずに投げ出してしまった開発ツールの数も、膨大なものになるはずです。
ただVBの場合、他の言語とは異なる原因がありました。単に難しいのではなく、「簡単だと思っていたのに、そうでもなかった」ということだったのです。その根底には、２種類の誤解がありました。
- GUIだから簡単?! -
VBは、GUIによってアプリケーションが開発できるツールであると言われます。GUIとはGraphical User Interface――つまりグラフィックス中心の操作感を示します。このことから、マウスでアイコンを貼り付ければ簡単にアプリケーションができ上がる――というイメージを抱いた人も多かったと思います。
確かにVBは、マウスで部品を貼り付けて画面をデザインできます。他の言語のように、最初からエディタでソースコードを記述する――ということはありません。Ｃ言語のようにプログラムの枠組みを文字で記述する必要もなければ、Ｃ
++のような難しい概念を理解する必要もありません。
しかし、VBがGUIによって助けてくれるのは画面、つまりフォームのデザインとそこを通じて実際に実行されるプログラムの本質部分とのつながりだけです。「プログラムの本質部分」とは内部の動きであり、これはソースコードを使って記述するしかありません。この部分は、いかにVBといえどもマウスでペタッ!とは行かないのです。
ところが、この本質部分を見ることなく、「部品を貼り付けるだけでプログラミングできる」という上辺のイメージだけを受け止めてしまった人が、案外たくさんいました。これには、初期の頃に雑誌などでVBを紹介した人たち(筆者を含めて)の責任もあるかと思います。が、VB以前のプログラミング手法に比べれば、VBのそれはまさに"マウスでペタッ!"に等しい簡便さでした。つまり「従来のプログラミングを知っている人にとって、VBはうそのように簡単に開発できる」ということだったのです。
ところがこの簡便さによって、VBはそれまでの難しいプログラミングをまったく知らない人たちまで、Windowsプログラミングの世界に引き込んでしまいました。
そういう人たちにとっての「簡単」とは、「難しいお勉強が不要」というニュアンスです。これが誤解の１つです。
- BASICだから簡単?! -
もう１つ、Windowsが広まりつつあった当時の状況の中で、プログラミングに取り残された人たちがいました。かつてパソコンのROM BASICでプログラミングを学んだ人たちです。
そこからＣやPascalへと進んでいけば、多少の困難はあってもWindowsプログラミングへと進む道が残されていたのですが、とにかくBASICの提供するインタプリタ環境は非常に気楽だったため、そこから先に進まなかった、あるいは進む余裕のなかったアマチュアプログラマーが多数いました。
その人たちにとって、ＣやＣ ++によるWindowsプログラミングは相当難しい、おいそれとは近寄れない敷居の高い世界だったのです。そこにVBが登場しました。頭に"Visual"と付いた"BASIC"です。「BASICなら分かる!」と思い立ち、VBに飛びついた人は大勢います。
このときVBに飛びついた人の大半は、(さほど具体的ではなかったにせよ)「Windowsで動作するあの懐かしいBASIC」というイメージを抱いていたはずです。しかし蓋を開けてみると、見慣れた懐かしいBASICとは月とスッポン、まったくの別世界が広がっていました。
サンプルのソースコードをよく見ると、"Dim"とか"For i = 1 To 100..."などと、見覚えのあるBASICライクな記述が確かにあります。しかしそれは、"How
many files?"に続いて"10"から始まる行番号が表示される、あの懐かしいBASICとはまったく異なる環境でした。
これが、もう１つの誤解です。
※１:Rapid Application Developmentの略。手早く迅速にアプリケーションを開発すること。RADツールはそのための開発ツール。
- 画面を感覚的に作れるのが利点 -
VBは、Microsoft BASICに始まるパソコン用BASICの言語構造を使って、Windowsのオブジェクトを操作する機構を実現しています。上記２つの誤解によってVBを「やっぱり難しい」と感じていた人は、気を取り直してもう一度VBに向き直ってください。
どんな開発環境も、今のところ「言語」と名の付くように「文字による処理手順の記述」が必須です。確かにすべてをGUIによって作成できる環境もありますが、その根底にはやはり「文字のソースコード」が介在しています。ユーザーからは見えないだけなのです。
それはコンピュータの本質が計算機であり、プログラムが「計算手順」を示した論理的な手順書である以上、ある意味で仕方のないことです。ただ従来のプログラミングでは、画面設計というさほど論理の介在しない(どちらかと言えば感覚的な要素の強い)作業までソースコードの記述を必要としていましたが、それがVBでは文字どおり感覚的に、GUIによって処理できるという点が重要なのです。
さて、以上はいわゆるアマチュアプログラマー、あるいはパソコン出身のプログラマーに関する問題でした。VBに壁を感じている人たちには、それらとは別の人たちもいます。プロのプログラマー、汎用機やオフコン出身のプログラマーです。
- 80×25から1024×768の世界へ -
特にCOBOLを使って業務用アプリケーションを開発していた人たちにとって、VB以前にまずWindowsの世界が相当異質なものだったはずです。Windowsでは、ディスプレイをピクセル(ドット)の集合と捉え、グラフィックスによってオブジェクトを操作します。80桁×25行のテキストベースの世界からそこに飛び込むには、相当な勇気と覚悟が必要だったはずです。
まず、入力画面の設計手法がまったく異なっています。マウスでテキストボックスをドラッグし、プロパティを設定して――という作業より、SCREEN SECTIONで文字数と表示位置を定めるだけの作業の方が、実ははるかに簡単です。
出力仕様にしても、ドットプリンタの印字開始位置と改行位置だけを考慮していれば良かったのですから、VBの方が格段に難しくなっています。しかし、時代はとっくの昔にWindows。いつまでも80桁×25行の世界にしがみついてはいられません。
- 業務アプリの本質は同じ -
確かにVBの顔、つまり表面的なイメージはCOBOLで業務アプリケーションを開発していた人に取ってなじみにくいものですが、ここで視点を変えてみましょう。先述したように、プログラムの本質部分はソースコードであり、これはVBでも変わりません。
文法が変わろうが、ソースの書き方が変わろうが、最終的に同じ目的のアプリケーションが内部で行なわなければならないことは同じです。オフコンやCOBOLで培ってきたことが、VBの前でまったく通用しない――ということはありません。
実のところ、変にDOSのC言語を生かじりしたような人たちより、COBOLプログラマーの方がVBに近い位置にいます。最大の理由は、目的とする内部処理を、明確にソースコードの集合として把握できる素養があることです。
プログラミングにおいて、文法の違いはさほど大きな壁ではありません。最大の障壁は、実は動作環境です。汎用機やオフコンのOSとWindowsはまったく異なる環境なので、その上で動作するアプリケーションや開発環境も大きく異なるように見えています。が、こと「業務アプリケーション」に関する限り、その本質部分にはまったく差異はありません。
異なるのが見た目だけだと気付けば、VBは恐れるに足るものではないと分かるはずです。
VBによるアプリケーション開発の第一歩を踏み出しましょう。本稿は、業務アプリケーションの開発経験はある程度あるが、WindowsプログラミングやVBははじめて――という方を対象としています。
そのため、既にVBを扱ったことのある人にとっては、誰でも知っている当り前のことも逐一取り上げる場合があります。逆に、業務処理に関する基本的な考え方は、「知っていて当然」という前提で説明を省略する場合があります。
もちろん、Windowsの基本操作や各部の名称など初歩的なことについても説明を省略します。この点をご了承ください。
- VBの起動～プログラムの選択 -
VBを起動すると、画面１のようなダイアログボックスがオープンします。「新規作成」パネルでは、VBで作成できるプログラムの種類が選択できます。ここでは「標準EXE」を選択して[開く]をクリックします。 |
|
「標準EXE」とは、Windows(95またはNT)で動作する一般的なWindowsアプリケーションを示します。つまり「普通のプログラム」です。
- VBの起動～フォームウィンドウ -
すると、画面２のようなウィンドウがオープンします。中央の白地のウィンドウが「フォームウィンドウ」で、その中にフォームオブジェクトが配置されています。この上に、ウィンドウ左側のツールボックスから部品(コントロール)を選んで貼り付け、フォームをデザインしていきます。
VBでは、このようにまず最初にフォームのデザインを行ない、アプリケーションの顔を作っていきます。COBOLを始めとする伝統的な言語は非常に目的指向的な要素が強いため、まず最初にデータ構造を設計します。COBOLではレコードの仕様を定めることが、第一の作業です。しかしVBでは、内部のデータ構造より先に「ユーザーに見える部分」「ユーザーと対話する部分」を組み上げます。
- 画面デザインから入るプログラミング
-
先に画面から作るということは、COBOLで言えば「真っ先にSCREEN
SECTIONあるいはREPORT SECTIONから書き始める」ようなものです。が、COBOLでそんな無茶なことはできません。FILEもWORKING
STRAGEも定まっていないのに、入出力仕様と密接に関連する部分など決められる訳がないからです。
しかしVBでは、画面のデザインが最優先です。と言うより、とにかくフォームのデザインを決めてしまわないと、次のステップに進めないのです。なぜならVBでは、フォームに貼り付けたコントロールに対して、ソースコードを記述していくからです。
- しかし基本は変わらない -
先にCOBOLではSCREEN SECTIONから書き始めることはできない――と書きました。が、これはあくまで仕様設計段階での話であって、実際にエディタでソースを入力する段階では、DIVISIONごとの概要が明確になっており、かつレコードの構造が明らかになっていれば、実はどの部分から書き始めても構わないことはご存じでしょう。ただ、規則にのっとってちゃんと全部記述しなければ、コンパイラを通過しませんが。
汎用機のバッチ処理など画面出力の存在しないプログラム、特に大量のトランザクションを次々と処理するようなプログラムでは、レコード設計こそ命――ということになりますが、そうではないパソコン向けの小規模プログラムでは、SCREEN
SECTIONからいきなりソースを書き始める人もいないではありませんでした。 VBでも、いやどのような言語でも、入出力仕様が明確になっていなければソースは書けません。VBではフォームから作成を始めますが、その前提として「明確な入出力仕様」の存在が必須です。
業務処理の本質は「受け取ったデータをいかに加工するか」ということですが、VBではそれ以上に「どのようにデータを受け取るか」が重要視されます。つまりユーザーとの対話の部分です。
- コントロールを貼り付けていく
-
プログラムをスタートさせたら、あとはカードリーダーやテープから大量のデータを読み込んでさばくだけ――といった処理も、VBで作れます。その場合もフォームは必須です。入力領域も何もなく、ただ「カードをセットしてください」というメッセージと[開始]ボタンがあればいいのです。
厄介なのは、対話型の業務アプリケーションでは入力領域がやたらと多くなる――ということです。特に伝票入力では、明細行が多数必要です。しかしこれについては、データベース操作のための便利なツールによって簡単に実現できます。詳しくは、回を追って紹介しましょう。
また、入力には通常のテキストボックスのほかに、チェックボックスやラジオボタン、ドロップダウンリストなど様々な形態のコントロールが使えるので、プログラムの望むデータを適切に入力できるよう、ユーザーを誘導するのに効果的です。
VBの画面作成工程は、とにかくフォームにコントロールを貼り付けることから始まります。この時点で、入力仕様は確定していなければなりません。
- 画面だけでも動く! -
無地のフォームにコントロールを配してみましょう。画面3のようにしてみました。これは、キーワードによって業務に関連する法令・規定・内規文書を検索するプログラムの開始画面です。
このような画面をマウスのドラッグで簡単に作れるところが、VBの最大の利点です。今の段階ではプログラムらしいことは何一つしていませんが、実行して動作を確かめることができます。
画面４が、まだフォームだけしか作っていないアプリケーションをテスト実行したところです。リストに項目を設定しておけば、このようにマウスで選択することもできます。無論検索のための処理はまだ皆無なので、本格的な処理はまったくできません。が、フォームに貼り付けたコントロールは、この段階で既に基本機能を満たしているのです。
画面１：新規作成するプログラムの種類を選択できる
画面２：VBの新規作成画面。無地のフォームが表示される
画面３：フォームにコントロールを貼り付けて画面をデザインする
画面４：ドロップダウンリストも機能する
VBと従来の言語との最大の違いは、ソースコードの位置付けにあります。VBではソースコードがすべてではなく、常にフォームやコントロールなどのオブジェクトとの関連の中に位置付けられています。
- コントロールとソースコードの関係 -
VBでは、ソースコードはフォームに貼り付けたコントロールごとに記述していきます。ここが、従来の言語と大きく異なる部分です。従来の言語なら、上から順に処理を記述していきました。特にCOBOLでは、一番の元となる仕様設計の構成に基づいて、ソースリストもDIVISION単位で順序良く並べられます。処理だけではなく、ソースの構造そのものにも順序があるのです。
一方VBでは、大きな意味での処理の順序は存在しません。既に説明してきたように、「このボタンがクリックされたらどうする」「あのチェックボックスが変更されたらどうする」というように、コントロールごとのイベント単位で処理を定めていきます。VBでは１つのまとまった処理を「プロシージャ」(procedure)と言います。
COBOLのPROCEDUREと同じで、「手続き」という意味です。この場合はイベントに対応するプロシージャなので「イベントプロシージャ」と呼びます。
イベントプロシージャは、例えばコマンドボタン"CmdStrat"のClickイベント――といったように、コントロールごと、イベントごとに独立しています。その中に記述されるソースには、当然「上から下」という処理の流れの原則が当てはまります。これは、ほとんどの言語に共通する原則です。
もちろん、IfやForなどの制御構造を作ることによって処理の順序は変更できますが、基本はあくまで「上から下」に向かって処理されていきます。
- １行だけのソースで動く! -
フォーム右上に配したコマンドボタンには"cmdClose"という名前を付けました。フォームのデザイン画面でこのボタンをダブルクリックすると、画面5のようなウィンドウがオープンします。これを「コードウィンドウ」と言います。
コードウィンドウには、コントロールのイベントに対応する処理の名前があらかじめ付けられています。cmdCloseのClickイベントに対応する処理なので、ここでは"cmdClose_Click"となっています。
ウィンドウ内には
Private Sub cmdClose_Click()
End
と表示されています。この2行の間に、「コマンドボタン"cmdClose"がクリックされたときに行わせたい処理」を記述していくのです。ここでは間にEndと入力し
Private Sub cmdClose_Click()
End
End
としてみます。
これでコードウィンドウを閉じ、再びテスト実行させてみると、[閉じる]ボタンをクリックしてウィンドウを閉じる――つまり、アプリケーションを終了させることができるようになります。
画面５：コードウィンドウにソースを入力する
今回は、VB最大の特徴であるフォームのデザインと、ソースコードとの関係を紹介してきました。まだ細かな規則については何も説明していないので、処理やプログラミング作法について具体的なことは取り上げませんでしたが、とにかく画面を作ってコントロールごとにソースを記述する――という、VBの基本的な操作がイメージしていただけたと思います。 |
