VBAから.NET Frameworkを使用する際のメモ

実験的にVBAから.NET FrameworkのSystem.Collections.ArrayListを使ってみるテストコードを書いてみたのだが、ノートPCでは動作するが、デスクトップPCでは動作しない症状(オートメーションエラー)に直面した。

クラスモジュール:Point
標準モジュール:Module1

デスクトップおよびノートパソコンの環境は下記の通り統一されている。

  • Windows 10 Pro 64bit
  • Office 365

原因を探ると、.NET Framework 3.5(3.0/2.0)有効化の有無で動作しなかったようだ。つまり何らかの操作にてノートパソコン環境は有効化されていたが、最近セットアップしたデスクトップパソコンではWindows10標準では無効化されているため動作しなかったという結論に至る。逆に.NET Framework4.0以降はVBAからアクセス許可されないということ。すなわち最新の機能は利用できない。だが、もともとVBAから.NET Frameworkの操作には制限があるとのことなので、利用場面は限定される。ArrayListそこそこ便利でした。

.NET Framework自体は今後もWindowsに残るけど、このようなバージョンによる制限は、将来的に.NET Coreへ移行する布石だろう。

新しい技術が出てくるたびに、勉強しなければならないプログラマーさんは大変ッス。これじゃあ、いくら時間があっても足りないわけですよ。

VBAには型宣言記号による型宣言方法が存在する

型宣言記号?

カルチャーショックという程でもないけど、VBAには古いVBの名残り?として「型宣言記号」というものが存在した。VBAを勉強して数年は経っているにも関わらず知らなかった。軽く後頭部を叩かれたような気分になったので、メモることにした。

Option Explicit

''型宣言記号の確認コード
Sub TypeSymbol()

    ''文字列型
    Dim ss As String
    Dim ss_$ 'ドルマーク
    
    ''整数型
    Dim n As Integer
    Dim n_% 'パーセント
    
    ''長整数型
    Dim l As Long
    Dim l_& 'アンパサンド
    
    ''単精度浮動小数点型
    Dim f As Single
    Dim f_! 'エクスクラメーション
    
    ''倍精度浮動小数点型
    Dim d As Double
    Dim d_# 'シャープ
    
    ''通貨型
    Dim m As Currency
    Dim m_@ 'アットマーク
    
    ''バリアント型
    Dim v As Variant
    Dim v_ '型宣言記号をつけない
    
    ''型確認
    Debug.Print TypeName(ss) ' String
    Debug.Print TypeName(ss_$) ' String
    
    Debug.Print TypeName(n) ' Integer
    Debug.Print TypeName(n_%) ' Integer
    
    Debug.Print TypeName(l) ' Long
    Debug.Print TypeName(l_&) ' Long
    
    Debug.Print TypeName(f) ' Single
    Debug.Print TypeName(f_!) ' Single
    
    Debug.Print TypeName(d) ' Double
    Debug.Print TypeName(d_#) ' Double
    
    Debug.Print TypeName(m) ' Currency
    Debug.Print TypeName(m_@) ' Currency
    
    Debug.Print TypeName(v) ' Empty
    Debug.Print TypeName(v_) ' Empty

End Sub

上記コードでは各種型別に、通常の方法と型宣言記号による方法の2パターンの変数を記述した。型宣言記号は宣言した変数に続き付加する。例で用いた宣言方法の場合、変数名と型宣言記号の間にアンダーバーが含む。これは違いを区別するために使用しているだけである。本来つける必要はない。つまり文字列型の場合、ss$と記述して良い。

後半は、宣言した変数の型確認をおこなっている。見事に同じ型名が返ってくる。それ以上の発見は無かったが、まだまだ知らないことがたくさんあることを実感した。

ところかわり・・・

さて、型宣言記号の存在を知らなかったわけだが、知ったところでコードに優位性が生まれる気がまったくしなかった。もちろん記号による省略でコード記述量が減るため、負担軽減と時間短縮には貢献するのだろう。しかしこの記述方法は使用することによりコードの可読性を低下させる可能性がある。結果として負担が増えるのでは?と疑問を感じた。

これは今よりもコンピュータに積むメモリが少なかったことに起因しているように思う。VBAの登場は1994年前後。その頃は2~8MBぐらいが主流。メモリリソースがシビアだったころの面影かな?

ひとりでコードを書くならば、ちょっと特殊なコードを書いて「オレ、かっこいい!」みたいな中二病的自意識過剰自己満足全開でもよいだろう。しかし2020年代はプログラミング人口が増え始めると想定される。誰もがプログラムを書く時代になろうとしている。そして、いつ誰が自分のコードを参考にするか分からない。その時、合理的で読みやすい整った平均的なコードであれば、それを真似てより良いコードを書く人が増えるのではないだろうか。

何はともあれ、嫌われプログラミング言語No.1の汚名を持つVBA(VB)を題材にこんなことを書いている時点で、説得力はあまり感じてもらえないだろう。Officeのデファクトスタンダード言語かもしれないけど、将来はモダンな言語へ移行をお願いしたいところです。

Officeを購入してきて、ンッじュウネん!

Officeを使い始めたのは高校時代だったかなぁ・・・。

購入したバージョンをまとめると、以下の通り。Officeは搭載する機能によって細分化されていました。フルバージョンはとても高い買い物だったと思います。

  • Office2000
  • Office2003
  • Office2010

初めて触ったのはOffice97。特に目的はなかったけど、手段としてExcelとWordの使い方を覚えるためにキーボードをカチカチ、マウスをポチポチしてました。ついでにブライン・・・じゃなくてタッチタイピングもこのころ身体が覚えてくれました。

その後、2000を購入したときにAccessとPowerPointを勉強しています。2003の購入動機はよくわからない。PC環境をWindows XPに移行したときになんとなく購入したのかもしれない。この時期からVBAに興味持ち始めて、チマチマとマクロで遊んでいたと思う。(触ってみてVBAってクソかもと思った)

そして現在も使っている2010。これはWindows 7 pro(64bit)へ移行したため、環境一新およびリボンインターフェイス慣れの目的で購入。(許されるならばVBAって使いたくないと感じていた)

2010以降は、2013の後に最新2016とパッケージ製品が登場しています。2018年後半には、いよいよ次期Office(2019?)が登場するらしいです。

ちなみに、パッケージ製品のほかに月単位もしくは年単位の使用料を支払うことで利用できるサブスクリプションタイプのOffce365も展開しています。こちらはパッケージタイプと異なり、月および年単位の使用料を払い続ける限り永続的にOfficeの最新機能追加やアップデートを受けられます。

それまで1世代ごとに購入してきたOfficeも、2010以降2世代経過しましたが欲しい動機がなかったため、購入に至っていない。

来年は、メインPC環境をWindows 10へ移行を考えています。このタイミングで次期Office購入を検討しています。なおWindwos 10環境でもOffice 2010はサポート(2020年までだったかな?)されている。2018年から流れてくるであろう製品情報によって、今後購入する・しないを考えたい。

にしても、手段としてOffice製品の使い方いろいろ勉強してきたけど、結局使う環境や理由が無ければ、時間の経過とともに忘れてしまい、いざ使おうと思うと学び直しになることに嫌気をさすことが過去何度もあった。Accessなんて使う機会ないのでほぼ忘れてしまっている。

どんな場面でもそうですが、資源も時間もお金も無限じゃないので、最近は「無駄なことに時間は割かない、必要ないなら学ばない、でも自分が興味を持ったり楽しいことならば、まず情報は得る」思考で考えています。

ちょっとしたスキマ時間の独り言でした。
(VBAなんて簡易VB言語捨てて、いろんな言語で操作できるようにしてほしいですよね。)