<HOME　　<お願い事項　　<Access2000 TOP　　　<Access97 TOP　　　<サイト内検索
Ac2002--VBAの沼　＞　［オマケ］DoCmdについて、など

「コマンドボタンをクリックしたら別のフォームが開いて出てくるようにしたい」 「コマンドボタンをクリックしたら別のフォームが開いて出てくるようにしたい」 「フォームを開いたら、新規にレコード追加ができるような状態にしたい」 「コンボボックスから何か選択した後、別のテキストボックスのカーソルを移動しておきたい」 「コマンドボタンをクリックしたときに、テキストファイルをインポートさせたい」

・・・・。
こういう、「なんかしたとき、なんかが起こる」ような仕組みは、ふつうは「マクロ」というオブジェクトを作って実現させます。
こういう「仕組み」のことを、「イベント駆動型（イベントドリブン型）」とか言ったりします。
VBAで何かしらプロシージャを作成するのも、マクロを作るのも、目的は同じです。

ちょっとだけ、余談です。
「自分はあまりマクロは使わないです、いつもVBAでやっちゃうんで」と言う人がたまにいますが、もしそれで「オレって上級者だからマクロなんてもんは使わないんだよね」という演出をしたいがための台詞ならば、それは大きな間違いです。
そういう人のことは心の中でくすっと笑ってやりましょう。
心の中で笑うだけにしておいた方が無難です。こういう人ってプライドバリバリ高いですから、怒らせると何を言われるかわかりません。

もちろん、意思を持って、マクロを使わずコードを書いている人もたくさんいます。
でも、「マクロは初心者向き、VBAは上級者向き」なんて勘違いしている人もけっこう人もいます。
ここまでお読みいただけてれば、決して上級者向きとかそういうことじゃないな、ということ、お分かりいただけてると思いますんで、皆さんはもう、そんなピントのずれたことはお考えでないと思いますけど、中途半端な言動で世間を惑わす人たちもいますからね。
マクロかVBAか、どっちがいいのか、なんて、「牛乳を温めるのに、お鍋に移してガスで温めるべきか、マグカップに入れてラップして電子レンジで温めるべきか」考えるのと同じです。どっちでもあったまればいいじゃないですか。どっちも難しかぁないけど、電子レンジにお鍋入れちゃまずいし、お鍋をあちこち眺めて「スイッチはどこ？」なんて探し回ってたらいつまでたっても温められない。やっぱ、双方の「使い方」をちゃんと知らないとならないですよね。
で、両方の方法を知っていれば、時と場合によって使い分けをすることもできるはず。

要は、基本的な知識を持ってさえいれば、どっちをどう使おうと、それは個人の自由であり、好みであるわけで、どっちが「上級」か、なんて構図は存在しないのです。

MS-Accessは「パソコンソフト」です。リレーショナルデータベースという特殊な分野に分類されることが多いので忘れがちですが、パソコンのソフトで、MDBというのもパソコンのファイルです。MDBファイルは、MS-Accessというソフトウェアが用意されているPCでのみ開くことができるファイル。MS-Accessというソフトに用意されている機能や考え方を使って、ひとつのデータベースを作るのです。

「上級者」の定義って、なんでしょう？自分の持ち合わせている知識に、パソコンソフトを合わせることですか？
うーん、そういう人もいるかもしれないけど、パソコンソフトなんて「使いこなしてなんぼ」でしょう。
まず、そのソフトの基本的な機能とか構造を理解して、その上で自分流に使いこなす・・・こういう人が「上級者」だと、わたしは思うんですよね。
どんなに簡単なソフトでも、どんなに初心者向きのソフトでも、短時間でそのソフトの基本をマスターできる人が、上級なんだと、そう思います。

Web系の開発をしている人とか、COBOLをやってた人とか（この「COBOLをやってた」っていうステータスがどうも理解できないんだけどなぁ）、Oracleマスターとか言う人たちの中には、MS-Accessをバカにする人、けっこういます。
でもね、それはちょっと違うんじゃないの？って、わたしは思う。
この人たちはエンジニアではなく、単に「Oracleに詳しい人」なんだろうなぁと思う。
「使いこなしてなんぼ」ですよ。もっともっと広い意味で。
会社の業務をシステム化する際の手段がたまたま「MS-Access」なだけであって、レベルが高いとか低いとか関係ないです。

ぜひとも「VBAを習得すること」だけを目的にしないでくださいね。
その先に、本当の目的があるのですから・・・。

他の人が作ったMDBやXlsで、めちゃくちゃたくさん複雑なコードを含んだものとか、けっこうありますよね。仕事で使うデータベースとかブックを前任者から引き継いだはいいけれど、はてこれはいったい・・・みたいな。で、よくよくコードを追っかけてみると、単にカーソルを移動させてるだけだったり、特定のセルに移動させてるだけだったり、どうでいいような処理がグダグダ書かれてるだけだったりします。見てると「VBAを使うために、会社の業務がある」みたいな感じ。違いますよ。そうなってしまってはいけません。「会社の業務をよりスムーズに行うために、VBAで仕組みを作る」のです。

「複雑なコードが書けること＝上級者」なんて、決して思わないでください。
「与えられたソフトウェアの機能や構造を理解して使いこなすこと＝上級者」です。
そのことを決して、忘れないでくださいね・・・。

逆に、「VBAがわからない」ということを、「初心者」「助けてもらわないと何もできない」ことへの代名詞（免罪符かな）に思ってる人も、いただけません。
VBAはあくまでも「手段」のひとつです。そこを取り違えてしまってはなりません。

余談はオシマイです。
ネットで調べ物とかしていると、いろんなことを言う人がいっぱいいて、ついつい焦ってしまうかもしれないけれど・・・。
焦らずじっくり取り組んでいきましょう。

マクロは、MS-Accessの中で、「なんかしたとき、なんかが起こる」という仕組みを作るために用意されている、MS-Access独自の機能です。
「マクロ」というオブジェクトの中に「アクション」と呼ばれるあらかじめ用意されている動作を選び組み合わせることで、ひとつの「動き」を作ります。お芝居のシナリオを作ってるみたいな感じですね。

通常は、この「マクロ」を駆使して、仕組みを作るものだと、わたしは考えてます。
なぜなら、マクロは、MS-Accessの中に用意されている「基本機能」だから。これを使いこなしてなんぼ、ですよね。
これらマクロアクションについて何も知らないということは、MS-Accessでどういう処理ができるのか全然知らないということになるでしょう。
マクロのアクションにどういうものがあって、「どういうときにどれをどう使うと、どういう結果になるか」を詳しく知っていること。
これって、とっても重要なことだと思うんです。
マクロを実際に使うかどうか、じゃなくて、マクロというものでどういうことができるのか・・・。これを幅広く知っていると、VBAのコードを作る際、とってもプラスになるんです。

したがって、マクロは、「マクロ」として保存して使うだけが用法ではありません。
マクロのアクションをVBAで記述することもありえるんです。というか、必要です。

例えば・・・。
「コマンドボタンをクリックしたら別のフォームが開いて出てくるようにしたい」なんてときには「フォームを開く」というアクションを使います。

引数という欄に、このアクションを実行する際必要な情報（どのフォームをどういうふうに開くのか、とか）を指定します。

これで、このマクロを実行したとき、フォームが開くようになるわけなんですよね。
あとは「いつこのマクロを実行するか」を考えて、コマンドボタンのクリック時のイベントのところに指定して・・・と、やってることはVBAでコード書いてるのと同じです。

この、「練習用フォームを開く」というマクロのアクションをVBAで書くとすると、

DoCmd.OpenForm “練習用フォーム”

こう書きます。DoCmdというのが、ミソですね。
読み方は何でもいいと思うんですけど、わたしは「どうーしえむでー」と読んでます。
ほんとうは「どうーこまんど」なのかしら。

Docmdというのは、マクロのアクションをVBAで書くときの決まり文句みたいなもんです。
ヘルプで調べてみると・・・（VBEのウィンドウの方のヘルプですよ）

DoCmd オブジェクトのメソッドを使用して、Visual Basic から Access アクションを実行することができます。アクションによって、ウィンドウを閉じる、フォームを開く、コントロールの値を設定する、などのタスクを実行します。

というようなことが書いてあります。
言葉遣いは難しいんですけど、とりあえずVBAでマクロのアクションを実行する際に使う命令語だと思ってください。

書き方としては、VBEでコードを入力しているときに、docmdと入力してから半角のドットを打ちます。

と、使えるマクロアクションの一覧が出てきます。
といっても日本語のアクション名じゃないので、「そのマクロアクションをコードで書く場合はどう書くのか」を知っておかないとなりません。
どう書くのかは、マクロウィンドウで、知りたいマクロアクションを選び、カーソルがその位置にある状態でF1キーを押して、ヘルプで調べておく必要があります。

「フォームを開く」のヘルプを見ると、「OpenForm」って書いてありますよね。
なので、Docmd.OpenForm　と書くのです。

あとは、「どのフォームを開くのか」という「引数」の部分の指定をします。
これは、他の関数と同じように、用法に沿って書く必要がありますので、一通りヘルプを確認しておくといいですね。
書き方の例とかもたいてい載ってますから・・・。

さらに、ヘルプにはこんなことが書かれています。

DoCmd オブジェクトでは、次のアクションに対応するメソッドはサポートされていません。 　"AddMenu/メニューの追加" 　"MsgBox/メッセージボックス" MsgBox 関数を使用します。 　"RunApp/アプリケーションの実行" Shell 関数を使用して他のアプリケーションを実行します。 　"RunCode/プロシージャの実行" 関数を Visual Basic で直接実行します。 　"SendKeys/キー送信" SendKeys ステートメントを使用します。 　"SetValue/値の代入" 値を Visual Basic で直接設定します。 　"StopAllMacros/全マクロの中止" 　"StopMacro/マクロの中止"

つまり、全部のマクロアクションが「DoCmd…..」で実行できるかというとそうでもなくて、別の書き方をしたり、マクロ特有の命令語なのでVBAでは使用できなかったりするものもあるよ、ということです。
この辺もちょっとチェックしておくとよいと思いますよ。

マクロをVBAに変換する、というのも簡単にできます。
コードの書き方に慣れないうちは、この機能を活用するといいかもしれませんですね。

ちょっとやってみましょうか。
保存したマクロを選択した状態で、メニューバーの［ツール］→［マクロ］→［マクロをVisual basicに変換］を選びます。

こんな感じのボックスが↓出てきます。

とりあえずこのまま変換してみましょうか。

と、なんか適当な名前のモジュールがひとつできて、中にFunctionプロシージャがひとつできました。

「練習用のフォームを開く」っていうところ、VBAのコードになってますよね。
とりあえず、マクロのアクションをコードで書いた場合どうなるのか、を、簡単に知ることができますよね。

この機能、なかなか便利なんですけれど・・・。こうやってコードを作ると、エラー処理とかが自動的にはいってきます。
エラー処理などについてはまだお話してないですけれど、こういうのを先に書いちゃうと、いったいどこでどういうエラーが出ているのかわかりづらくなっちゃいます。フォーム名が間違っていてフォームが開けない場合でも、エラーメッセージ出して終わっちゃいますからね。なんでエラーが出ているのかわからずに「Accessのバグかしら？」なんてトンチンカンなことを考えちゃうといけませんから・・・。

エラーに関する配慮などは、ひととおり他の処理が完成してから取り組むことにいたしましょう。