アクセス非連結フォームのテキストボックスの制御

いつも楽しく勉強させていただいております。

Access2007、win7で前任者が作ったものを元に類似のシステムを作ることとなりました。
その中にあるフォームで私にとってよくわからないものがあります。

そのシステムとは検索条件を入力し、条件に一致したレコードを表示するというものです。
条件を設定するフォームはレコードソースプロパティは空白、つまり非連結のフォームです。
したがって検索条件を入力するテキストボックスのコントロールソースプロパティも空白です。

こういった場合「入力する値は数字だけに限定」といった制御をするなら、入力規則プロパティを設定するか、更新前のイベントでコードを書くかするものだと思っていました。

ところがこのフォームにはそれらしき設定がまるでないのです。

それなのに数字以外の値、たとえば"a"などを入力すると
「このフィールドに入力した値が正しくありません。たとえば、数値型のフィールドに文字列を入力しました。」というメッセージをちゃんと表示し、誤った入力を受け付けません。

どなたかこの謎を解明してくださるとうれしいのですが。

前任者に直接聞けるといいのですが、その人は派遣社員でして契約終了後は連絡が取れないのです。

No.1 ベストアンサー 回答者： m3_maki 回答日時： 2013/01/04 17:37

「書式」プロパティに

数値を表す書式　（例えば 「#,##0」 など） が
設定されているのでは？

この回答へのお礼

m3_makiさん、さっそく回答いただいたのに金曜の夕方から調子を崩し、週末は風邪で寝込んでいました。
申し訳ありません。

書式プロパティの設定を見たところ、[標準]になっていました。
別のフォームを作ってテキストボックスを二つ貼り付けました。
ひとつは書式プロパティがなしのまま、もう一つは[標準]にしてみましたが、
後者は数値しか受け付けないことがわかりました。

おっしゃる通り書式プロパティが効いていたようです。

お礼日時：2013/01/07 10:23

No.3 回答者： DexMachina 回答日時： 2013/01/07 23:30

No.2です。

m3_makiさんのご回答で解決されたとのことなので、今後のご参考に、ということで。

> チェックのロジックを共通化できるのがメリットということですか。

はい、前任者の方にそういう意図があった可能性を推測しての回答でした。

例えば、テーブルの各フィールドに入力するデータを非連結フォームで
一旦受けた上で、コマンドボタンのクリックなどでテーブルに反映、という
形を採る場合、フォームモジュールで対応すると、テーブル/フォームが
異なる場合は、また同様のコードを記述することになると思います。

ここで、例えば
　a)記録先の各フィールドに一対一で対応するクラス
　　→DataAccessObject(DAO)のFieldオブジェクトを経由して
　　　 『データ型』や『入力規則』『値要求』などを取得するとともに、
　　　当該フィールドに対応するコントロールの更新時(→WithEvents
　　　使用)に、それに相当するチェックを実行
　b)記録先となるテーブル/クエリに対応するクラス
　　→上記「a」のクラスを格納するコレクションを定義しておき、記録先
　　　のフィールドに対応する上記「a」のクラス群を保持
　　　(フィールド名とコントロール名を引数とするメソッドを用意しておき、
　　　同メソッドで「a」クラスのインスタンスを生成し、コレクションに追加)
という2つのクラスを定義しておけば、当該フォームのOpenイベント等で
　・上記「b」クラスのインスタンスを格納する変数の定義
　・上記「b」クラスのインスタンスの生成
　・上記「a」クラスのインスタンスを生成し、コレクションに追加するメソッド
　　の呼出(Split関数と「For Next」ステートメントを使用)
というコードを記述するだけで、「テーブルのフィールドに定義された各種
プロパティへのチェック」を、フォーム毎に個別にコーディングする手間が
省ける、ということです。
(更にクラスの定義に凝れば、テーブルの『入力規則』では対応できない
　「ユーザー定義関数による入力規則の定義」なども行えるかと
　思います：
　但し、この部分は各フォームのOpenイベント等での個別コーディングが
　発生することになります)


・・・と、長々と書きましたが、私自身ではまだこれに相当するクラスを
作成したことはありませんので(汗)、細部に間違いがありましたら
ご容赦願います。
あくまで、イメージということで・・・(汗)

この回答へのお礼

DexMachinaさん

詳しい説明をありがとうございます。
オブジェクト指向の技法を本格的には使用したことがないのですが、
イメージ的にはなんとなくわかります。

コントロールの多い複雑なフォームを作るときにきっと役に立ちそうです。
教えていただいたリンク先も参考にもっと勉強してみたいと思います。

お礼日時：2013/01/08 09:44

No.2 回答者： DexMachina 回答日時： 2013/01/05 00:02

m3_makiさんが提示されている設定以外での可能性として、

a)フォームの『開くとき』(Open)イベントで、フォームの『レコードソース』プロパティや
　コントロールの『コントロールソース』プロパティを設定している
　(レコードソースにはテーブル/クエリの他、SQL文も指定できるため、例えば
　　抽出条件に併せて適切なSQL文を動的に生成したり、データ保護のために
　　テーブルを別のMDBファイルに保存した上で(リンクテーブルではなく)SQL文で
　　接続をしたり、といった場合、上記のようなことをします)

b)データ型のチェックを行うクラスを『クラスモジュール』に定義し、各コントロールの
　データ編集時にはそちらでチェックを行わせている
　(クラスモジュール上で「Private WithEvents objTB As TextBox」という記述と
　　「Private Sub objTB_AfterUpdate ～ End Sub」という記述をしておいた上で、
　　「Set objTB = Forms("フォーム1").テキスト0」とすることで、「フォーム1」の
　　「テキスト0」が更新された場合、クラスモジュール側で記述した処理を行う
　　ことができます)
　イメージとしての参考：
　http://www.excellenceweb.net/vba/class/userform_ …

も、参考として挙げておきます。
(ただ、メッセージの内容がAccessの組み込みのままっぽいので、「b」の可能性は
　低いかとは思いますが(汗))

この回答へのお礼

DexMachinaさん、回答ありがとうございます。

結果から言うと今回はm3_makiさんのおっしゃるとおり書式プロパティの設定でした。
まさか[標準]が数値しか受け付けないということだとは思わなかったので、何かよほど高度なテクニックかと勘違いしてしまいました。

いろいろ詳しく説明してくださってありがとうございます。

ひとつ教えていただきたいのですが、「データ型のチェックを行うクラスを『クラスモジュール』に定義し、各コントロールのデータ編集時にはそちらでチェックを行わせている」といった方法は、各コントロールの[更新前]でチェックするのとどう違うのでしょう。

チェックのロジックを共通化できるのがメリットということですか。

お礼日時：2013/01/07 10:31