Visual Basic 2005(VB2005)のすすめ
(ご注意)記述は2006年時点  

1.はじめに

 最初の試行 〜 VB.Netの憂鬱

 VB.Netが初めて流布されたとき、これは面倒だなと思った。 あらかじめおおよその事はアナウンスされていたから、使ってみて面食らう程の事も無かったが、ちょっと使おうとする気には成れなかった。 手持ちのVB6によるアプリケーションソースを適用したら、ばく大なエラーが出て動きそうも無かったからだ。 しかも、VBコントロールのPropertyなど全滅で、どこをどう変えれば良いか見当もつかなかった。

 これはえらい事だと思った。 MicrosoftのVB開発者はなぜこのような改変を実施したのか理解できなかった。 宣伝文句によれば、Internet Serverアプリケーションの開発を「容易ならしめる為」とかも書かれてあった。 しかし、VB6時代から既にI.netServerアプリ開発済みの筆者としては、そこに全くメリットは感じなかった。 VB6でもWin.APIを使えばI.netServerアプリは可能だったから。

 2度目の試作 〜 雪解け

 それでしばらく放置していたが、前から持っていた仕事を終えた時点で、再度考え直してみた。 Windowsアプリケーションの開発・ベンダーに身を置く者としては、やはり無視できないだろうと考えた。 それで初心に戻る気分で、最初から調べてみた。 主にVB2005のHelpメニュからだ。 既存アプリケーションソースの適用はこの際考えず、全く新規に練習用プログラムを作ってみた。 当面必要な要素を最低限盛り込む事とした。 むしろ機能確認用のプログラムというものだ。 このときはVB2005で行った。

 この試作プログラムに盛り込んだ要素は次のものだ。
  ・VBアプリで使用する標準的なコントロール
   VB6で言う Label、Textbox、Listbox、CommandButton、Picturebox、Shapeなど
  ・ファイル選択操作、読み書き処理
  ・図形表示(直線、円など、折れ線、ポリゴン塗り潰し)
  ・画像(イメージ)の表示、縮小表示など
  ・印刷機能

 結果としてこれが良かった。 VB2005のメリットが見出せたから。 何がメリットかと言うと、大まかには2点ある。 (以下、次節)

 (注釈)VB.Netの初版が出たのは2002年。 その後2003年に改訂版が出て、
      2005年にさらに改定され、VB2005と名称も改められた。(現行版)



2.VB2005のメリット

 (1) 図形・画像の表示:処理能力の増大

 一つは、図形表示機能が強力になった事で、また標準機能としてPolygon表示がサポートされた事だ。 (従来のVB6では、ポリラインもポリゴンも表示できなくて、Win.APIを使うしかなかった。 )同時に、図形表示が軽快になった。

 これ(表示が軽快)はやや分かりにくいかもしれないが、AutoRedrawプロパティを廃止し、代わりにPaintイベントを新設してFormの再表示をアプリケーション側にまかせたからである。
 従来、AutoRedraw=Trueとしておくと、いつも自動で再表示されたが、これが、特に地図表示のように大量ベクター表示の場合の、低速処理の原因であった。 また同時にメモリー消費も大きかった。 (これは巨大なベクター地図を縮小表示する場合に顕著だった。 )
 VB.NetからAutoRedrawの仕組みを変えたので、この結果(大量データの場合の)図形表示が軽快になった。

 また類似の結果だが、イメージ(画像)表示も簡単で、軽快になった事もある。 従来、(AutoRedraw=Trueとしておくと)あまり巨大なイメージは表示できなかった。 PCのメモリーにより異なるが、ほぼ 4,000×3,000Pixel ぐらいが限界だった。 これでは地図画像を扱うには不十分である。
 しかしVB2005では、その長さ2倍(面積4倍)ぐらいの画像でも表示できる。
 (参考:主記憶 1GB PCの場合、9,600×6,400Pixel までOKだった。)

 (2) その他機能の守備拡大(.NetFrameWork利用による)

 もう一つのメリットは、.NetFrameWorkの機能が標準で使える事だ。 これはつまり、元々VBで不得手だった機能が、.NetFrameWorkの利用によって可能になった、という事だ。 そういう機能は多い。

 例えば、Bitmapデータも直接扱えるようになった。 また、ささいな事だが、Sub FormをModoless(非同期)表示して、なおかつ最前面に置く事なども、である。 従来は、Win.APIを使わねばどうしようもなかったこれら機能も、.NetFrameWorkにより全て標準で実現できるようになった。(他にも多くあると思う。)

 (3) メリットの発見から、違いの克服へ

 これは(遅ればせながら)新発見であった。 これだけのメリットがあれば、VB2005への乗り換えは十分価値あると思った。 一部には、VB2005は従来より難しくなった、との考えもあるが、これはいくらか言えるだろう。 しかし、従来的なやさしい使い方もできる。

 それでも、VB6の標準コントロールと言われていたものの、Property・Method・Eventはほとんど変わった。 このあたりはもう、慣れによるしかないだろう。 なぜ変わったか、たぶん他の言語、C#やC++と同じにする為だろう。
 見方を変えれば、この事によって、コントロールの使い方に慣れてしまえば、C#など他言語の理解も早いと考えられる。

 VB6からVB2005への違いの要約など、各所に書かれてあるが、言語仕様の変更などわずかとも言えるか。 むしろ、コントロールのプロパティ・メソッド・イベントの表記が変わった事、これが一番大きいと考える。 ここを克服してしまえば、VB2005への移行は容易だろう。 そこで本論は、ここに重点を置いてまとめた。 具体的には次の節を参照のこと。

 現実には、言語仕様の変更は幾らか、あるいはもっと有るのだが、VB2005で書かれたソースを見る分には、びっくりする程の違いは無い、とも言える。

 (注1)個々の機能について、VB自体の機能か、または.NetFrameWorkの機能か、今の所、正確には把握していない。 できれば、VB固有の機能は避け、開発を.NetFrameWorkで揃える、との考え方もあるようだ。 が、この点はあまり賛成しない。

 (注2)筆者としては、VB6による旧ソースプログラムの変換はあまり念頭にない。 つまり新規開発分からの、VB2005の適用である。(後に、VB6_VB2005アップグレード手順追加した)

 (注3)本論は、VB2005を全般的に解説したものではない。 VB6との違いの要点についてまとめたもので、VB2005として重要な事項が抜け落ちている可能性はある。 しかし、どのプログラム言語にしても、言語仕様の全貌を知らなくてもプログラミングは出来るものだ。 (筆者はそういうスタンスでいる。 )



3.違いの要約

 VB2005になって、コントロールは大幅に変わった。 従来無かったものが新たに用意されたのはもちろん、逆に従来はあったがVB2005から無くなったコントロールもいくらかある。

 処理状況インジケータとして使われていたShapeコントロールは無くなった。 これは、Labelの横幅(Width)変更で行いなさいと紹介されていた。 (現実には、そんなふうに、こちらの求めに応じて紹介されているわけでは無いので、これらの事を見つけ出すのは、少なからず骨が折れた。 )

 FormのLoad/unLoadも変わった。 Loadイベントは表面的に同じだが、unLoadイベントは無くなり、代わりにFormClosingイベントになった。 また、unLoadメソッドはCloseメソッドに変わった。 たぶん、ソフト的に厳密な動きも変わっていると思う。

 また、VB6ではコマンドボタンの.Value=Trueとして、別コマンドをプログラムから起動できたが、これも変わった。 つまりVB2005では、Buttonコントロールの、PerformClickメソッドとなった。 などなど、書けば長くなる。 従って、次の表にまとめた。

  → VB6:VB2005 コントロール対応表 、また 関数対応表
  → VB6からVB2005へのアップグレード: ひとつの方法 (←FileIO と時刻 の例もある)

 なかなか文章や比較表では説明できない部分もある。 それで、次の サンプルコード も参照してもらいたい。

 (補足・訂正)       (2008.07.15)
 サンプルコードやアップグレード方法の中で、ファイル(StreamReaderやStreamWriter)定義ステートメントを下記○のように書いた。文法的にやや分かり難いが、簡潔な短文形式が良いという考え方である。意味合いとして△が分かりやすいが、冗長な表現は避ける。
 ○ Dim myRdr As New System.IO.StreamReader(fNam, System.Text.Encoding.Default)
 △ Dim myRdr As System.IO.StreamReader = _
      New System.IO.StreamReader(fNam, System.Text.Encoding.Default)
 なお、上記△の書き方でも、文法的に誤りではない。

 また、「Imports ステートメント」や「Try...Catch...Finally ステートメント」、また「Using ステートメント」についても、本論では言及していない。 言及していないものは他にもあるだろう。 それらについてはマニュアルやMSDNヘルプを参照してもらいたい。

[いくらか補足]

・開発環境もVB6と異なるが、初期設定を変えて、従来型に近づける事はできる。
・Debug.WriteLineの出力先は、[デバッグ]・[ウィンドウ]メニュで選んだ「イミディエイト」
 Windowになる。
・Console.WriteLineの出力先は、同メニュで選んだ「出力」Windowである。



4.考察

 VB2005への乗り換えは、VB6で使っていたコントロールと同等の、VB2005のコントロールについて慣れれば、あまり問題無いと思う。
 しかし、.NetFrameWorkなど、普通に使える機能はVB6時代よりかなり多い。 また、クラスのインスタンスを定義して(オブジェクト)、それを使うのが本来的らしい。 これらにより、VB6よりやや難しくなった、という見方は当たっているように思う。

 個人差はあるだろうが、これらを全て覚えるのは困難と思う。 それで多くのプログラムソース サンプルを、手元に持つ事が重要と思われる。 「コード スニペット操作」より、自分として必要なサンプルソースを用意して置き、これをいつでも参照できる体勢を作っておく事が重要ではないかと思う。

 また、ソースプログラムのファイル構成は従来より複雑になった。 筆者はまだ十分に把握していないが、(1exeに対応する)VBプロジェクトをフォルダ単位に管理するのが良いようだ。

 (終)

サイト先頭へ戻る