スキップしてメイン コンテンツに移動

投稿

ラベル(VBA)が付いた投稿を表示しています

アーリーバインディングとレイトバインディング

はじめに、と後から、というくらいの違いは知ってはいるけど。 改めてどう違うのか?を調べてみた。 書式の違いはこう(VBA) ・アーリーバインディングの例 Dim myApp as Excel.Application Set myApp = Application ・レイトバインディングの例 Dim myApp as Object Set myApp = Application もう一例 Dim myApp as Object Set myApp = CreateObject("Excel.Application") まあ、CreateObjectで書く事が多いよね。 でも、やっぱりアーリーバインディングで書く事には相応の違いがあるそうな。 一つは、たとえばメソッドの存在チェック。 アーリーバインディングでは、"myApp"内に当該メソッドが存在するかはコンパイル時にチェックされる。 一方レイトバインディングではプログラムが実際に実行されるまではチェックがされない。 つまり、動かしてみないと判らない、という事。 開発やテストの事を考えるとアーリーバインディングのほうがやっぱりいいんだろう。

Accessで環境変数を使う

今回のお題は、ディレクトリの特定の仕方について。 Accessで処理するファイルを、ある場所、具体的にはユーザープロファイルの”ダウンロード”フォルダからアプリのディレクトリに移動したい。 ただ、”ダウンロード”フォルダはログインしているユーザーによって絶対パスが変わってくる。それをどうするか? 今回の場合、ユーザーのリテラシーがそれほど高くなく、ネットからダウンロードされたファイルを、ユーザー自身がファイル選択ダイアログから選んで指示するのは避ける、という判断となった。 一応、ネットからダウンロードされるファイルの保存先はユーザー別の”ダウンロード”フォルダ、という事は保障される前提。 ダウンロードされるファイル名は名前付けルールにそって、識別子のお尻にタイムスタンプが付く。 ただ、Access側での処理のタイミングの問題で、同時に複数のダウンロードファイルを処理するケースも想定された。 個人的には、バッチファイルを同期でアクセスから実行して…、で良いんじゃない?と思った。 それなら環境変数でユーザープロファイルのパスが取れるから。 でも他からの判断でアクセス内で完結させる方法をとる事となった。 で、結局はWSHの ExpandEnvironmentStrings メソッドを使う事にした。 このメソッドは環境変数(%XXXX%)文字列をあたえるとそれの展開結果を返してくれる。 なんで、ExpandEnvironmentStrings("%userprofile%")とすると、ログインユーザーのユーザープロファイルパスが帰ってくる。 なお、これをAccessで使うには参照設定として「Windows Script Host Object Model」 を追加しないといけない。 また、オブジェクトを使うにはアーリーバインディングで書く必要がある事に注意。 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>...

ACCESSでリンクテーブルを張りなおししたら起きた事 #NAME?

先の投稿で『拾い出しシステム』の明細情報を読むために、リンクテーブルを都度張りなおす、という方法について書いた。 今日はその関連で起きた事を書き留めておく。 物件管理番号はメインフォームで指示され、その指示された物件管理番号の明細レコードをサブフォームで表示する、という構造だ。そこで物件管理番号が変わったら、リンクテーブルを張りなおす、という処理を行ったわけ。 最初の内はそれだけでなんら問題なかった。 サブフォームの項目のコントロールソースはリンクテーブルのデータ項目に設定していて、リンクテーブルを張りなおしした後、サブフォームをリクエリーするだけでうまく表示内容が切り替わった。 ただここからが問題だった。 明細レコードには品目コードがある。品目のコードは規格コードと色コードの組み合わせで構成されていて、『拾い出しシステム』ではこの二つは分離して管理されている。 一方基幹システムの品目コードは規格コード+色コード。つまりこのままでは基幹システムに突っ込めない。 そこでサブフォームのレコードソースをクエリーに変更して、基幹システム用の品目コードを演算(規格コード+色コード)するように変更した。 そうしたら、” #NAME?”です。非演算項目は問題なく表示されるんだけれど、演算項目はだめ。メインフォームを開いた一発目はちゃんと演算項目も表示するんだけど、管理ナンバーの変更を行うと演算項目は表示できない。 結局、どう落ち着けたのか?というと、リンクテーブルを更新した後、サブフォームのソースオブジェクトを再定義する方法で安定した。 "sub_meisai"というサブフォーム用のフォーム定義があり、メインフォームでこれまた”sub_meisai”というサブフォームが定義されている。 サブフォーム”sub_meisai”のソースオブジェクトをフォーム”sub_meisai”に定義しなおしている。 =========================================== Me.sub_meisai.SourceObject = "sub_meisai" ===========================================

ACCESSで動的にリンクテーブルの元ファイルを変更する方法

今回の事案は初めてのケースだった。 ある事業で、顧客に対してある種の設計サービスを行っている。 住宅関連なのだが、ハウスメーカーが、こういう設計の住宅、といった図面をよこしてきて、その図面からうちの商材をパーツごとに必要な数を拾い出しして見積もりを行い、販売する、というものだ。 住宅、という事でまあ『物件』と称され、上記のサービスを実現しているのが『物件拾い出しシステム』と呼ばれている。 で、この『物件拾い出しシステム』、全物件のヘッダー情報はファイルサーバー上の.mdbファイルに保管されているのだが、どの商材をいくつ、あの商材をいくつ、という『拾い出し』した結果の明細情報が、物件の管理ナンバーをファイル名とした別の.mdbファイルに格納されている、という構造なんだ。 今回受けたオーダーは、この『物件拾い出しシステム』の情報を使って、SAPScriptで受注伝票を突っ込む、というもの。開発プラットフォームはAccess。 で、タイトルのとおりの事をしないといけない破目になった。 各物件別の明細情報はファイル名以外はテーブル構造やテーブル名は共通。ファイル名は先に書いたとおり物件管理番号で、配置されるディレクトリもルールで決まっている。 そこで、ヘッダーファイルから管理番号を選択すると、明細情報を呼び出すためにリンクテーブルの接続先ファイルを各明細別mdbファイルに切り替える、という処理をした。 具体的にはこう。 =========================================== Const conmyDbPath = "\\サーバー名\物件データ" '明細ファイルへのパス生成文字列 Const conmyTbName = "T_拾い数量合算"          '明細情報へのリンクテーブル Dim dbsSys   As DAO.Database 'データベースオブジェクト Dim myDb As DAO.Database '明細用データベース Dim meisaiTb As DAO.TableDef 'テーブル(T_拾い数量合算) Dim pKanriNo As String '物件管理ナンバー pKa...

対処例:Accessフォームでチェックボックスが思うように設定できない

開発プラットフォームとしてAcccessという事は多い。 そして何気に不思議な動作をする事が多いのも事実。 今回であったのは、フォームに置いたチェックボックスが、フォームを開いた際に思ったように振舞ってくれない、というもの。 このチェックボックスは規定値=FALSEで設定してあって、人の操作以外でこのチェックボックスの値は操作していない。 そしてこのチェックボックスを置いたフォームを開くと… 問題のチェックボックス、チェックがついた状態で描画される!!! こまったチャンである。 時折は意図したとおりにOFFの状態で開く場合もあるものの、まれ。 ここはしっかりユーザーの操作(チェックボックスをONにする)に基づき、関連の項目を入力してもらう、という動作をさせたいし、また他へのI/F項目でもあって、しっかりさせたい。ちなみに、TripleState プロパティは Falseに設定してある。 簡単にググッてみたものの、ちょっと同様の事例や対処は見つからず。いくつか試したが、うまく行かない。 で、結論から書くと、こういう対処をした。 Form_OPENイベントの際に、問題のチェックボックスに以下の操作を実行 ・問題のチェックボックスにフォーカス設定 ・問題のチェックボックスに対して、SendKeys でスペース(" ")一文字投げつけ ・問題のチェックボックスの Value 値を確認。True の場合、もう一回SendKey でスペース(" ")一文字投げつけ 発想としては、チェックボックスがカレントな状態のとき、スペースキーで値が操作できる事を思い出し、ぶつけてみた。 でも、実は最初はうまく行かず。 はて? で、 SendKeys のリファレンスを改めて眺めて、 Wait オプションがある事を思い出した。 解説するまでもないが、これが True の場合、そのキーが処理されるまでVBAは次の実行をまつ。デフォルトでは False で実行される。なので、Accessが、なげつけられた?(いや、自分で自分に投げているわけだから…)スペースキーを受け取る前にVBAが進んでるか?と思い、以下に書き換えてやってみた。 SendKeys " ", True ...