t-hom’s diary

主にVBAネタを扱っているブログ…とも言えなくなってきたこの頃。

プログラムコード中に値(あたい)は登場しない

VBAに限らず全てのプログラミング言語で言えることだが、コード中に値(あたい)が直接登場することは無い。
最近、「値とは何か」ということを掘り下げて考えることがあり、ようやくこの結論に行きついた。

たとえば、数字の「1」。これは一般的に値だと理解されるが、表面的には単なる文字にすぎない。
「ひとつ」という概念を表した文字だ。

「1」という値が現れるのは、その文字を見た人の頭の中である。
値は確かに存在するが、書かれた文字は単なる記号でしかない。人が理解することで、初めて値が現れる。

プログラミングにおいても同じことが言える。
コンピューターは物事の概念を理解しないが、しいていえばコンピューターにとっての値とは、CPUが直接処理可能な「電気信号」である。

ただしブログ上に電気信号を書き表すというわけにもいかないので、便宜上スイッチのON・OFFを1と0で表した二進数で説明する。

たとえば次のコードを考えてみる。

Debug.Print 2 + 3

仮にCPUが32ビットだとすると、
「2」は「00000000000000000000000000000010」に変換され、
「3」は「00000000000000000000000000000011」に変換され、
CPUで加算されて「00000000000000000000000000000101」になり、
「5」という文字に変換されて出力される。

プログラム中に現れる「2」や「3」は値ではなく式である。
式と聞くと数式を思い浮かべる方が多いと思うが、本来の意味は「何かの事物や構造を記号で書き表したもの」を指す。
たとえば「2」は2という概念を表した式だ。

このように特定の値を直接的に指す式のことを、リテラルと呼ぶ。
リテラルの和訳は「即値」といい、これまで私はリテラルを式でもあり、値でもあると考えていた。

しかし、リテラルは単に式であり、値ではない。
つまりコード中に現れるこれまで「値」と呼ばれてきたものは、すべて「式」だ。

この視点でFizzBuzzを見てみよう。

Sub FizzBuzz()
    Dim i As Integer
    For i = 1 To 100
        If i Mod 15 = 0 Then
            Debug.Print "FizzBuzz"
        ElseIf i Mod 3 = 0 Then
            Debug.Print "Fizz"
        ElseIf i Mod 5 = 0 Then
            Debug.Print "Buzz"
        Else
            Debug.Print i
        End If
    Next
End Sub

文法的には、こういうことになる。

Sub 識別子()
    Dim 変数 As 型名
    For 変数 =ToIfThen
            Debug.PrintElseIfThen
            Debug.PrintElseIfThen
            Debug.PrintElse
            Debug.PrintEnd If
    Next
End Sub

「式」という表記が、すべての例外を吸収してくれる。

ザッツ、シンプル!ビューティフォー!

裏付け

以下はVBAの言語仕様書
VBA Language Specification(英語)

この76~77ページにFor文の定義がある。

For文の定義

for-statement = simple-for-statement / explicit-for-statement
simple-for-statement = for-clause EOS statement-block "Next"
explicit-for-statement = for-clause EOS statement-block ("Next" / (nested-for-statement ",")) bound-variable-expression
nested-for-statement = explicit-for-statement / explicit-for-each-statement
for-clause = "For" bound-variable-expression "=" start-value "To" end-value [stepclause]
start-value = expression
end-value = expression
step-clause = Step" step-increment
step-increment = expression

For文の定義の訳

for-statement = simple-for-statement / explicit-for-statement
for文 とは シンプルなfor文 または 明示的なfor文 である。

simple-for-statement = for-clause EOS statement-block "Next"
シンプルなfor文 は for節 ステートメントの終わり ステートメントブロック Next で構成される。

explicit-for-statement = for-clause EOS statement-block ("Next" / (nested-for-statement ",")) bound-variable-expression
明示的なfor文 は for節 ステートメントの終わり ステートメントブロック (Next または (ネストされたfor文とカンマ)) 束縛変数式 で構成される。

nested-for-statement = explicit-for-statement / explicit-for-each-statement
ネストされたfor文 とは 明示的なfor文 または 明示的なfor-each文である。

for-clause = "For" bound-variable-expression "=" start-value "To" end-value [stepclause]
for節 は For 束縛変数式 = 開始値 To 終了値 [step節] で構成される。

start-value = expression
始値 は 式である。

end-value = expression
終了値 は 式である。

step-clause = Step" step-increment
step節は Step step増分 で構成される。

step-increment = expression
step増分 は 式である。

参考

VBAの言語仕様書の定義はABNFというメタ言語で記述されている。基本情報技術者試験で出題されるBNFを拡張したものだ。
ABNFの定義はRFC4234 http://www.rfc-editor.org/rfc/rfc4234.txt を参照(英語)

以上。

学習において、疑問を抱えたまま次のページをめくる勇気

何かを学んでいると、まだ説明されていない箇所に対して色々と疑問が湧いてくることがある。たしかに、分からないというモヤモヤした気分のまま次に進むのはなんとなく気持ち悪いものだ。

一般的に学習において疑問を持ち、自主的に調べるのは良いこととされるけれど、最近思うのはひょっとすると一概にそうとも言えないんじゃないかということ。

私がまずいと思うのは「分からない。嫌だ。」という疑問に対する不寛容さである。

例えば自分で調べてみたものの疑問が疑問を呼んでさらに混乱し、結果的に一歩も動けなくなるという事態に陥る危険性もある。特に独学の場合は適切なアドバイスが受けられないため、疑問に対する不寛容さは挫折につながりやすいのではないか。

以前、物事は全てがつながった時に初めて完全に理解できるという趣旨の記事を書いた。
thom.hateblo.jp

物事を理解するにはそれ相応のステップが必要であり、地道に学んでいく努力も必要である。疑問があって先に進めない、躓いてしまうというのは、ある意味ではそうしたコツコツとした地道な努力を嫌い「すぐに結果が欲しい」という甘えなのかもしれない。

とりあえず、疑問は疑問のまま受け入れて、今は分からないけれど次に進んでみようという勇気も必要なんじゃないかと思う。

ただこの記事を鵜呑みにして何も自分で調べないという姿勢もそれはそれで学習においてマイナスだと思うので、そのあたりはバランスが大事。

高品質なコードを短時間で編み出すには

プログラムのコーディングで一番時間を消費するのは「思考」と「試行錯誤」である。

コーディングスピードが落ちることを嫌って極端に短い変数名をつけたり、一つのプロシージャで一気に書ききったりするとコードが把握しにくくなり、「思考」に時間をとられ、うまくいかない時の「試行錯誤」に時間をとられ、結果的に相当に時間をロスしてしまう。

私が普段のコーディングで大層な変数名を付けたり、プロシージャを分割したり、クラスモジュールを使用したりするのは、コードを把握しやすくして頭の負担を減らし、思考と試行錯誤に費やす時間を大幅にカットするためだ。

わざわざクラスモジュールなどという大層なものを持ち出してきやがってという批判は時折目につくのだけれど、これは「美しいコード第一主義」などではなく、単にそれを使ったほうが早く作れて、メンテナブルで、ついでに美しいからだ。

高品質なコードを短時間で編み出すには、急がば回れである。

VBAの知識の依存関係の整理を試みる

※今回の記事は基本的に自分用の備忘録です。

VBAの学習における知識の依存関係の整理を試みた。
試みたというのは、お世辞にも成功したとは言えない為である。

書籍でプログラミングを学ぶ際は、ふつう1ページずつ読み進めていく。
これに対して、実際の知識体系は必ずしもシーケンシャルに整理できるわけではない。

たとえばオブジェクトを正しく理解しようと思ったら、中身がどうなっているのか知る必要がある。つまりオブジェクトの知識はクラスの知識に依存すると考える。
f:id:t-hom:20180504194038p:plain

クラスはモジュールなので、前提としてモジュールの知識が必要になる。また、プロパティ・メソッドの理解には前提として変数とプロシージャの理解が必要になる。
f:id:t-hom:20180504194349p:plain

そんな風に整理していった結果。。こうなった。
f:id:t-hom:20180504193300p:plain

知識の依存関係をある程度表すことができたかなとは思うけれど、見て分かりやすい図ではないし、実際のところはこれより更に複雑だと思う。相互依存もあるはず。

VBAに限らず、知識の依存関係というのは有向グラフになっていて、その学習順序は巡回セールスマン問題を抱えているのではないかという着想を得た。

きちんとグラフを定義して、その最適経路を求めれば、最も効率の良い説明順序が求められるだろうか。

理解度の整理(追記)

ただ実際のところクラスを知らなくてもオブジェクトは使えてしまうんだよなぁ…と考えてたところ、「そうか、これは理解度の問題だ」と気づいたので追記。
理解度を図るバロメーターについてもざっくりと整理してみた。

たとえば以下のように知識Bが知識Aに依存していたとする。
f:id:t-hom:20180504201657p:plain

知識Bを単体で学習したとき、知識Bの理解度が1、知識Aを学んだ場合、知識Bの理解度は2になると考える。
逆に、知識Bを学んだことで、より知識Aの理解が進むということも考えられる。何等かの関係がある2つの知識がその理解において完全に一方通行であるとは考えにくい。※ただし矢印を両向きにすると分かりづらくなるのでグラフ上は、より強い依存関係のある方を採用する。

つまり知識Aを単体で学んだ場合に比べ、知識Bを合わせて学んだ場合、知識Aの理解度も2になると考える。

サンプルとして知識A~Dの依存グラフとその最大理解度を描いてみた。
f:id:t-hom:20180504203107p:plain

その知識自体を学習したときに1、関連する項目を学習したときに項目ごとに1レベル上がるという整理。
厳密に言えばその知識自体の学習と、依存元の学習と、依存先の学習で、それぞれその知識に入ってくる経験値って違うんだろうな。
でもシンプルに整理したほうが活用はし易いのでそれは置いておこう。

なんでこんなことを考えているのか(追記2)

なんでこんなことを考えているかというと、発端としては私がブログ記事を書く際に、「この記事を読むには知識Aと知識Bが必要です。」という風に、依存関係をライブラリの参照設定のように書けたら、わざわざ毎回同じような説明を書かなくても済むなぁと思ったから。

↓この先、妄想の世界なので注意。

要は知識のモジュール化である。
知識のモジュールはフォーマットだけ決めておいて、誰でも代替モジュールを作れるようにする。決められたヘッダの付いたパワポ1枚とかでも良いし、ブログのようなメディアの記事1本を1モジュールとしても良い。

学習する人は、ジェネリック医薬品のように、自由に代替モジュールを選んで学習することができる。変数はAさんのモジュールで学習し、関数はBさんのモジュールで学習する。オブジェクトは複雑なのでAさんのモジュールをメインにしつつもBさん、Cさんのモジュールで知識を補完するなど。

既刊のVBA書籍を買ってきてバラバラに切り刻んでモジュール化する手もあるか。。でも著作権がある以上オープンな場に出せないから自由に参照させるってわけにもいかないし、書籍の場合は前後で依存関係を考えて編纂されてるので切り出した単品をモジュールとするのは無理があるか。。

ということで今のところアイデアを温めているだけ。何も作る予定はない。

以上、そういう学習方法があるとおもしろそうだなぁという妄想でした。

Excelのセキュリティ設定と怪しいファイルの対策

Excelには、悪意のあるマクロによってコンピューターが被害を受けることがないようにいくつかの防御機構が備わっている。
しかしExcelマクロの解説書・解説サイト等では利便性の観点からか、設定を無効化しましょうという方向での解説が多く、セキュリティリスクについては「注意しましょう」という漠然とした勧告か「自己責任で」という免責のみで具体的に何をどう気を付ければ良いのかが書かれていないことが多い。

今回は、これらの防御機構の紹介と、正しい活用方法、外した場合の具体的なリスクについて説明する。
Excel 2013を基に紹介するが、これらの機能はExcel 2010にも存在する。(2007にも恐らくあるけれど、持っていないので不明)

目次

(1) 保護ビュー

説明

Excelの初期設定では、インターネット等のネットワーク経由で入手したファイルは次のように、保護ビューで開くような設定になっている。
f:id:t-hom:20180503230028p:plain

保護ビューはファイルを安全に閲覧することに特化したビューアで、一切の編集ができない。煩わしいことに、社内ネットワーク経由で入手した正当なファイルまでインターネット経由と判定されてしまうが、セキュリティに気を配るのであればたとえ社内ネットワーク経由で入手したとしても原則編集の必要が無いファイルは保護ビューのまま閲覧するのが安全である。

設定箇所

ファイル→オプション→セキュリティ センターからセキュリティ センターの設定ボタンを押し、左のメニューから保護ビューを開く。
f:id:t-hom:20180503230355p:plain

煩わしいので設定ごと無効化を推奨する記事も多いが、ファイルに悪意のあるコードが埋め込まれていた場合はコンピューターに被害を与えることも考えられるので、基本的には編集が必要かつ安全が確認されたものだけ個別に保護ビューを外すという使い方がオススメ。

保護ビューを外したファイルを再度保護ビューに戻す方法
基本的に一度安全を確認したファイルのはずなので、クリアする必要性はあまり無いが一応紹介。

セキュリティ センターの設定から信頼済みドキュメントをクリアすることで、保護ビューに戻すことができる。
f:id:t-hom:20180503233031p:plain

(2) 標準ブック形式へのマクロ保存不可

説明

Excel 2003まではマクロの有無にかかわらず、Excelブックの拡張子は「xls」だったが、Excel 2007以降はマクロが保存できない「xlsx」と、マクロが保存できる「xlsm」に分かれた。従来の「xls」や新しいバイナリ形式「xlsb」もサポートしているが、基本的にはマクロを利用しないファイルは「xlsx」とし、マクロを利用するファイルは「xlsm」とすることが望ましい。

熟練者がその気になれば悪意のあるマクロを作ることもできるため、マクロを使わないファイルではそもそもマクロを使えない「xlsx」形式にしてしまうことで、無用なリスクを減らすことができる。

ちなみに保存した後でファイル名の拡張子だけ変えてもダメで、以下のようなエラーになる。
f:id:t-hom:20180503232051p:plain

Excelはすべてお見通し。きちんと名前を付けて保存のダイアログから正しい形式を選択するべし。

(3) セキュリティの警告

説明

標準の設定では、マクロ付きのファイルを開く際に以下のような警告が表示され、マクロが一旦無効にされる。
f:id:t-hom:20180503232756p:plain

単にコンテンツを有効化してくださいと書かれている記事が多いが、なんでもかんでも有効化してはダメで、自分で作成した安全なマクロと信頼できる入手元から取得したファイルに限定してコンテンツを有効化すると良い。インターネットから入手したファイルは基本的に信頼性が低いものと考え、安易にコンテンツの有効化を行わないこと。

保護ビューとの違いはマクロを実行する以外の操作は自由に行えるという点である。
ファイルの編集もできるし保存もできる。マクロの編集もできる。ただ実行ができないというだけ。

入手元が完全に信頼できない場合、マクロが無効化の状態のままコードを読み、安全性を確認してから有効化すると良い。
コード確認の際のポイントをいくつか挙げてみた。

  • 完全には理解できなくとも、ある程度処理の流れが読めるコードであること。
  • わざと難読化されているコードや、プロジェクトが保護されていて閲覧できない場合はコンテンツを有効化しない。
  • 参照設定とCreateObjectを確認し、マクロが謳っている目的とかけ離れたオブジェクトが参照されていないことを確認する
  • ファイルシステムオブジェクトやファイル操作関連の関数が利用されている場合は特に内容を理解し、意図しないファイル操作が行われないことを確認する
  • 標準モジュールにAuto_Openプロシージャがあれば、特に注意深く処理内容を確認する。
  • ThisWorkbookモジュールにWorkbook_Openプロシージャがあれば、特に注意深く処理内容を確認する。

対象のコードを読むスキルが足りない場合、熟練者にお願いするか、マクロの利用を諦めたほうが無難である。

コンテンツを有効化したファイルを再度無効化に戻す方法
保護ビューを外した場合のクリア方法と同じく、セキュリティ センターの設定から信頼済みドキュメントをクリアすることで、コンテンツ無効化に戻すことができる。

設定箇所

セキュリティ センターのマクロの設定から「警告を表示してすべてのマクロを無効にする」を選択すると上記の設定になる。これが一番お勧め。業務で一切マクロを利用しない場合は一番上の「警告を表示せずにすべてのマクロを無効にする」でも良い。
f:id:t-hom:20180503235302p:plain

(4) VBAによるマクロの書き換え防止

説明

VBAではExcelブックを開いてそのブックのマクロの内容をマクロで書き換えるといった処理も可能であるが、これは標準では無効化されている。なぜ無効化されているかというと、マクロによるマクロの書き換えができるなら、悪意のあるマクロによって、正当なマクロファイルに悪意のあるコードを埋め込むことができてしまうから。
これはマクロウイルスの感染の基本的な仕組みである。

設定箇所

前項と同じ画面で「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」のチェックが外れている状態が安全。
f:id:t-hom:20180503235302p:plain

チェックを付けると、前述のような高度な処理が可能になりプログラミングが捗る場合がある。このブログでもこの設定を外さないと実行できない便利なマクロを紹介している。しかし、設定を外すとマクロウイルス感染の危険性は高まるので、これまで紹介してきた保護機能を活用してより注意深く実行するマクロを選択・確認する必要がある。また、面倒でも入手元が不明なファイルを開く前にはこの設定を無効に戻してから開く方が安全である。

まとめ

Excelにおけるセキュリティの基本は、不必要に設定を緩めないことである。必要が生じたら、その都度、必要な分だけ個別に対応すること。そしてファイルの安全性を注意深く確認すること。そうすれば無用なリスクを避けることができる。

プログラミング言語はコンピューター語ではなく人間のための言語

プログラミング言語とは何か。
初心者に向けて、よく次のような説明がなされる。

コンピューターは日本語や英語で指示しても理解できない。だからコンピューターが理解できる言葉、つまりプログラミング言語でコードを書く必要がある。

プログラミングを学び始める段階ならこの説明で何の支障もない。

と、以前までは思ってたんだけど最近は、初めからきちんと伝えておいたほうが良いんではないかという気がしてきたのでこの記事を書いた。

プログラミング言語は本当はコンピューター語ではなく、人間のための言語である。だから動けば何でも良いわけではなく、基本的には人が読むことを想定してコードを書くべきである。

プログラミングから実行までの流れ

人間がアイデアをプログラムコードに落とし込むと、コンパイラまたはインタープリタと呼ばれるソフトウェアがそれを機械語に翻訳し、最終的にコンピューターによって実行される。
f:id:t-hom:20180430104346p:plain
※ただし、間に中間言語が挟まったり、仮想マシン上の実行だったりと言語によってこの流れは必ずしも同じではない。

人間が機械語を効率よく読み書きできるなら、コンパイラインタープリタは要らない。
機械語とは、以下のようなコードになる。

0100101011110101011101010100001...
※イメージです。内容はデタラメ。

コンピューターは0と1しか処理できないのだ。

これを読んで理解しろというのは無理がある。
だから、コンピューターにもっと簡単に指示を出すために、人間が読めるプログラミング言語が設計され、翻訳者となるコンパイラインタープリタが作られた。

プログラミング言語が作られたワケ

人間が話す言葉(自然言語)は時と場合で意味が変わり、また表現も無数に存在するためにプログラミングに適さない。もしコンピュータが解釈を間違えたために飛行機が墜落したり、大事な取引の金額を間違えたりしたら洒落にならない。だから厳密に意味を定義され、それ以外に解釈できないような言語が必要だった。そして作られたのがプログラミング言語である。

このように形式的に意味が定義されている言語を形式言語という。
つまりプログラミング言語は人間のために設計された形式言語である。

主張

人間の人間による人間のためのコードを書くべし。
プログラミング言語は、そのために作られたのだから。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

VBScript ドラッグ&ドロップでファイルをAccessDBに登録する仕組み

PCのファイルは通常「フォルダ分け」によって整理される。
ところがフォルダ―ツリーを使った整理は実際のところそんなにうまく機能しない。
なぜなら、コウモリ問題が存在するから。

コウモリ問題とは、物事を単一の基準で分類していくと両方の基準に合致した場合に詰む事象を言う。
イソップ寓話の「卑怯なコウモリ」が由来だとのこと。

例えばプロジェクトAフォルダと、手順書フォルダが別の場所にあり、プロジェクトAに関する手順書をどちらに入れるべきかといったものが代表的。片方にだけ入れると反対側を探して時間を浪費するリスクがあり、両方に入れると二重管理で内容が枝分かれするリスクがある。

この問題に対する解決策の一つとして、タグ付けによる管理がある。タグは一つのファイルに複数付けることができ、関連するファイル群を瞬時にリストアップできる。

一応Windowsのファイルにもタグをつける仕組みはあるけれどちょっと面倒なのでVBScriptAccessを使って簡易システム化してみた。
といっても登録部分はAccessの機能を殆ど使わず、VBScriptからADOで登録する形式だ。

作成するシステムの解説

スクリプトにファイルをドラッグ&ドロップすると用途や入手方法、より適切な新しいファイル名、タグを尋ね、それらを入力するとAccessDB上に登録される。その際に一意の番号を発行してファイル名の先頭に付加する。
特に人からもらったファイルはファイル名を変えてしまうと「あのファイル」と言われたときに分からなくなるけど、自分の言葉で適切にファイル名を付けておかないとそれはそれで分からなくなるので、新旧名称をDBに登録できるようにした。
AccessDB上にファイルを添付してしまうことも技術的には可能と思われるが、今回はそれはせず、保管場所は一旦元の場所を保持する仕組みにしている。

Accessファイルの準備

FileDB.accdbというファイル名で適当な場所に作成。
私の場合は "C:\Users\thom\Documents\FileDB.accdb" とした。

FileMasterというテーブルを作り、以下のフィールドを作成。
f:id:t-hom:20180416010510p:plain

VBScriptのコード

コードは以下の通り。RegisterFiles.vbsというファイル名にした。自分のOSが64Bitなので32Bitで動作を試してないんだけれど、基本的にはこのままで動くはず。動かなければ64Bit対策と書かれた部分をバッサリ削除したら動くかもしれない。

'64bit対策ここから---------->
Dim Sh 'As WScript.Shell
Set Sh = CreateObject("WScript.Shell")

Dim Processor: Processor = Sh.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
Dim Systemroot: Systemroot = Sh.ExpandEnvironmentStrings("%SYSTEMROOT%")

Function Quote(x) 'As String
    Quote = """" & x & """"
End Function

Function ArgsToString() 'As String
    Dim ret 'As String
    If WScript.Arguments.Count > 0 Then
        For Each a In WScript.Arguments
            ret = ret & Quote(a) & " "
        Next
        ret = " " & Left(ret, Len(ret) - 1)
    End If
    ArgsToString = ret
End Function

If Processor = "AMD64" Then
    Sh.Run Quote(Systemroot & "\SysWOW64\wscript.exe") _
        & " " & Quote(WScript.ScriptFullName) & ArgsToString
    WScript.Quit
End If
'<----------64bit対策ここまで

Dim FSO 'As Scripting.FileSystemObject
Set FSO = CreateObject("Scripting.FileSystemObject")

Call Main

Sub Main()
    Dim dic 'As Scripting.Dictionary
    Set dic = CreateObject("Scripting.Dictionary")
    For Each arg In WScript.Arguments
        Set f = New FileInfo
        f.FullPath = arg
        f.Init
        dic.Add arg, f
    Next
    
    For Each k In dic.Keys
        AddDB dic(k)
    Next
    WScript.Echo "登録が完了しました。"
End Sub

Sub AddDB(o)
    Const dbFile = "C:\Users\thom\Documents\FileDB.accdb"
    Set cn = CreateObject("ADODB.Connection")
    cn.Open "Driver={Microsoft Access Driver (*.mdb, *.accdb)}; DBQ=" & dbFile & ";"
    Set rs = CreateObject("ADODB.Recordset")
    Const adOpenKeyset = 1
    Const adLockOptimistic = 3
    rs.Open "FileMaster", cn, adOpenKeyset, adLockOptimistic
    rs.AddNew
    rs.Update    '←この後参照するAutoNumber型のrs.Fields(0)を確定させるために一度更新をかける。
    o.FileNumber = rs.Fields(0)
    rs.Fields(1) = o.OriginalFileName
    rs.Fields(2) = o.GetFrom
    rs.Fields(3) = o.GetBy
    rs.Fields(4) = o.Description
    rs.Fields(6) = Now()
    o.ChangeFileName
    rs.Fields(5) = o.NewFileName
    rs.Fields(7) = o.Tag
    rs.Update
    rs.Close: cn.Close
End Sub

Class FileInfo
    Public FullPath
    Public OriginalFileName
    Public Description
    Public GetFrom
    Public GetBy
    Public NewFileName
    Public FileNumber
    Public Tag
    Sub Init()
        OriginalFileName = FSO.GetFileName(FullPath)
        GetFrom = InputBox("「" & OriginalFileName & "」の提供者名を入力してください。")
        GetBy = InputBox("「" & OriginalFileName & "」の入手方法を入力してください。")
        NewFileName = InputBox("「" & OriginalFileName & "」に、より適切な新規ファイル名を入力してください。")
        NewFileName = NewFileName & "." & FSO.GetExtensionName(FullPath)
        Description = InputBox("「" & NewFileName & "」についての説明を入力してください。")
        Tag = InputBox("「" & NewFileName & "」に付けるタグを入力してください。")
    End Sub
    Sub ChangeFileName()
        NewFileName = "F" & Right("000000" & FileNumber, 6) & "_" & NewFileName
        FSO.MoveFile FullPath, FSO.BuildPath(FSO.GetParentFolderName(FullPath), NewFileName)
    End Sub
End Class

試しにtest.gifというファイルをドロップすると諸々の質問がなされ、それに答えていくとDBに登録される。そしてファイル名も新しくなる。
f:id:t-hom:20180416012808p:plain

f:id:t-hom:20180416013053p:plain

64bit対策について

今回一番苦労したのが64bit対策。StackOverflowで解決策を見つけたんだけれど、勘違いしてドはまりした。
64bitOSではSystem32フォルダに64bit用のバイナリが配置されていて、SysWOW64フォルダに32ビット互換用のバイナリが配置されているということらしい。てっきりSystem32が32Bit、SysWOW64が64bitだと思ってたのでここで3時間ほどロス。
恐らく諸々の互換性のために標準のシステムフォルダはSystem32で固定化しているのだと思う。

環境変数の%PROCESSOR_ARCHITECTURE%を確認すれば32bit環境か64bit環境かが分かるので、64bitだったらSysWOW64フォルダ内の32bit版wscriptを呼び出す。
ちなみに%PROCESSOR_ARCHITECTURE%は64bit版WindowsAMD64となっている。AMDのCPUはもちろん、IntelのCPUでもAMD64。ややこしいけど、CPUアーキテクチャ名なので仕方がない。

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。