スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

オートフォームの不満点

  さて、オートフォームでとりあえず作ったフォームで大きく機能的に問題があるのはどこでしょう。

1.新規入力をするときに、いちいち新しい空のレコードまで移動してから入力しなければならないが、開いた直後に直ぐに入力できないか。=> 新規入力と修正・削除画面の切替

2.生徒の情報と家族の情報を一つの画面でまとめて入れたい。=> 生徒と家族の連携

3.修正・削除するときに該当のレコードを捜すときに移動ボタンでひとつひとつ表示していかないといけないので、データが増えたときに大変。=> 検索機能の追加

4.生徒番号を手入力するのは面倒。新規入力する時点で、自動で採番できないか。==> 生徒番号の採番

 更に他にも各コントロールの細かい要望をあげていくといろいろ出てきます。オートフォームではデフォルトとして入力項目はテキストボックスで生成されます。しかし実際にはコンボボックスなり、リストボックスなり、チェックボックスなりの項目に最適なコントロールにする必要があります。具体的に見ていきます。

【F_生徒番号】
1.姓漢字、姓かな、名漢字、名かな
漢字を入れたらかなも同時に入力できないか。

2.性別
男と女しかないのでコンボボックス又はチェックボックスにしたい。

3.生年月日、入学年月日、卒業年月日
入力書式を日付型にしてスラッシュの入力は省略したい。

4.学年
数値範囲のチェックを入れたい。

5.郵便番号、住所都道府県、住所市区郡、住所町名、住所ビル名
郵便番号を入力したら住所欄に自動的に表示させたい。

【F_家族】
1.家族番号
自動的に付番したい。

2.続柄
選択式で入力したいのでコンボボックスにしたい。

 次回以降で一つ一つ実装していきますが、まずは「新規入力と修正・削除画面の切替」について考えてみたいと思います。

関連記事
スポンサーサイト

テーマ : データベース
ジャンル : コンピュータ

フォームのプロパティ

  オートフォームでフォームを作成するとフォーム名は自動的に連結したテーブルと同名のフォーム名が付けられます。前にも述べたとおり、オブジェクトが違えば名前が一緒でも問題はありません。しかし、名前を見ただけでテーブルなのかフォームなのかを判別できた方がやはり便利なので、フォームの場合は「F_」を付加するようにしましょう。名前の変更でフォーム名を「T_生徒番号」を「F_生徒番号」、「T_家族」を「F_家族」に変更します。

生徒番号フォーム

 まずは実際にオートフォームで生成されたフォームでデータを試しに入力してみましょう。F_生徒番号をダブルクリックで開き、適当に全フィールドに値を入力して最後のフィールド(メールアドレス携帯用)のところでEnterキーを押すと、データが登録され、次の入力が出来るようになります。とりあえずこれでデータの新規入力はどんどん出来ます。(①)

 しかし、一旦フォームを閉じて再度開くと最初に入力したデータが表示されています。追加でデータを入力したい場合は移動ボタンで「新しい空のレコード」をクリックし、空フォームを表示させます。(②)

 それでは既存のデータを修正・削除したいときはどうするでしょう。
 フォームを最初に開いたときは必ず1件目が表示されているので、修正・削除したいレコードまで移動ボタンの次のボタンをクリックしていって該当のレコードを表示させます。(③)

 修正するときは修正したいフィールドを直接修正し、次のレコードに移動するか、フォームを閉じれば入力内容が保存されます。ESCキーを押すと、修正がキャンセルされます。

 削除する場合は、レコードセレクタを選択し、DELキーをクリックすると確認メッセージが表示され、OKをクリックすると、削除されます。(④)

 まずはここまでの動きを確認した上で、フォームのポイントとなるプロパティを確認していきましょう。

フォームのプロパティ

①規定のビュー:単票フォーム
フォームの表示形式として他に『帳票フォーム』『データシート』等があります。帳票フォームは一覧形式でデータをまとめて入れる場合に用います。データシートはテーブルを開いたときに表示される形式です。今回は1件ずつデータを入力する形式として単票フォームを使います。

②レコードセレクタ:はい
レコードセレクタはレコード自体を選択状態にする為に必要となります。選択して削除等を行います。

③移動ボタン:はい
移動ボタンでレコードを前に進めたり、前に戻したりします。

④スクロールバー:水平/垂直
データが1画面に入りきらない場合にスクロールバーを移動することにより表示させます。

⑤コントロールボックス:はい
コントロールメニューつまり次の閉じるボタンや最大化/最小化ボタンを一切表示させない場合は「いいえ」にします。

⑥閉じるボタン:はい
ウインドウ右上の『×』ボタンのことです。通常は終了ボタンも別個設けてそのボタンで終了させます。終了時にそのフォームを閉じるだけでなく、何か処理をさせたい場合(関連テーブルも同時に更新する等)、『×』で終了されると困ります。そういう時に閉じるボタンを表示させないようにします。

⑦最大化/最小化ボタン:最小化/最大化ボタン
ウインドウ右上の最大化/最小化ボタンの表示/非表示を切り替えるときのプロパティです。画面のサイズを固定にしておきたい場合には「いいえ」にします。

⑧データ入力用:いいえ
データ入力専用にする場合は「はい」にします。その場合は同一画面で修正・削除が出来なくなってしまうので、この場合は「いいえ」にしておきます。

⑨追加の許可:はい
追加入力を許可する場合は「はい」にします。

⑩削除の許可:はい
データの削除を許可する場合は「はい」にします。

⑪更新の許可:はい
データの更新を許可する場合は「はい」にします。
表示専用のフォームにする場合は⑧、⑨、⑩、⑪は全て「いいえ」にします。

 F_家族の場合も項目が違うだけで基本的には同様です。

 オートフォームで出来るのはここまでです。しかし、実際の使い勝手を考えると不満な点がいろいろと出てきました。次回では具体的に実務では使えないと思うところをいろいろ検討していきましょう。
関連記事

テーマ : データベース
ジャンル : コンピュータ

連結フォームと非連結フォーム

  オートフォームで作成したものを前回はデザイン的な側面から検討してみましたが、今回は機能的な面で検討してみます。

 まずフォームの設計でポイントなる点は連結フォーム非連結フォームという事です。連結フォームとはテーブルとフォームがダイレクトに連携していてフォームにデータを入力するとリアルにテーブルにデータが保存される仕組みをいいます。オートフォームはこのタイプです。非連結フォームとはテーブルとは直接結びついておらず、単なる入力項目が並んだフォームと言うことです。

 非連結フォームではどの段階でテーブルに格納されるかというと登録ボタンのイベントとかにコードを組み込んで、DAOなりADOというデータベースエンジンを操作する言語を用いて書き込んでいきます。細かいタイミングや条件、同時に行う複雑な処理等本格的にシステムを作るにはやはり非連結フォームにし、言語を駆使して作成する必要があります。

 しかし、この連載のミッションとして最初にあげたとおり、なるべくコードを書かないで処理を実現するという基本方針に則りここではオートフォームで作成された連結フォームをそのまま使います。

 それでは今後非連結フォームは使う事はないのかというとそんなことはありません。入力画面の他に非連結フォームが活躍する場面が2つあります。

 一つはメニューです。メニューに各フォームやレポートの起動用のボタンを貼り付けてクリックすると開くという処理を組み込みますが、その時のメニューフォームはどのテーブルとも無関係ですので非連結になります。又、レポートを開くときに出力範囲の指定や印刷・プレビューの指定など指示画面を用意する事になりますが、その時も非連結フォームを使います。入力された値は何かのテーブルに保存するのが目的ではなく、レポートの抽出条件に使われます。

 連結フォームがどのテーブルと連結しているかを指定しているのが「レコードソース」プロパティです。プロパティとはそのオブジェクトの属性を指します。プロパティはデザイン時に固定で指定しておくか、プログラムで実行時に動的に変更、取得する事が出来ます。

生徒フォームのレコードソース            家族フォームのレコードソース
 生徒フォームのレコードソース 家族フォームのレコードソース 
 フォーム全体がどのテーブルに連結しているかを指定しているのがレコードソースと言いますが、フォーム上の各コントロールがテーブルのどのフィールドに紐付いているかを指定しているのが「コントロールソース」です。オートフォームでは自動的に紐付いていますが、念のため一つ一つの入力フィールドのコントロールソースプロパティを開いてどのテーブルフィールドに紐付いているか確認してみます。

生徒フォームのコントロールソース
生徒フォームのコントロールソース

家族フォームのコントロールソース
家族フォームのコントロールソース
 
次回ではフォーム全体に指定するプロパティというものを更に検討していきましょう。
関連記事

テーマ : データベース
ジャンル : コンピュータ

家賃管理システム

 ひとくちに家賃管理システムといってもそれが家主向けなのか管理会社向けなのか会計事務所向けなのかによって管理する視点が違います。又、店子さんの規模によっても管理項目が違います。駐車場まで管理するのか電気代・水道代はどうするのか。今まで開発した家賃管理システムでパターンを3つに分類してみました。

 まずは比較的規模の大きいオーナーを複数管理する管理会社向けのシステムです。

家賃管理パターン1(メニュー) 

家賃管理1(メニュー)

 法人契約の場合など、契約者と入居者が違う場合に対応しています。又、入居時と退去時の日割り計算にも対応しています。駐車場のみの家賃にも使えます。

家賃管理パターン1(契約情報入力)
家賃管理1(契約情報入力)

 通常家賃の他、請求時に電気・水道・灯油のメーター管理に応じた請求計算が出来るようになっています。

家賃管理パターン1(請求入力)
家賃管理1(請求入力)

 入金処理では基本的に通帳に記帳されたイメージをそのまま入力できるようになっています。

家賃管理パターン1(入金入力)
家賃管理1(入金入力)

 パターン2では小規模な家主向けの家賃管理システムになっています。基本的な流れとしては入居者入力→請求入力→入金入力となります。

家賃管理パターン2(メニュー)
家賃管理パターン2(メニュー) 
 
請求入力といっても基本的に月々の家賃は決まっているので、請求月を入力して登録するだけです。

家賃管理パターン2(請求入力)
家賃管理パターン2(請求入力)

 入金入力では入金月を入力し、部屋番号を入力していくだけです。家賃が全額入金されない場合の一部入金も可能です。

家賃管理パターン2(入金入力)
家賃管理パターン2(入金入力)

 この家賃管理表がこのシステムでの白眉といってもいいでしょう。一部入金、複数月入金に対応して月毎の未収金の管理が可能になっています。

家賃管理パターン2(家賃管理表)
家賃管理パターン2(家賃管理表)
 
 パターン1と似ていますが、管理項目がシンプルになっています。

家賃管理パターン3(メニュー)
家賃管理表パターン3(メニュー)

家賃管理パターン3(契約情報入力)
家賃管理パターン3(契約情報入力)

家賃管理パターン3(請求入力)
家賃管理パターン3(請求入力)

家賃管理パターン3(入金入力)
家賃管理パターン3(入金入力)

 家賃管理表では前月繰越額と今月分の家賃と今月の請求額の管理となっています。

家賃管理パターン3(家賃管理表)
家賃管理パターン3(家賃管理表)

 パターン4では請求入力がありません。入居者入力時点の固定の家賃、共益費等に基づいて自動で請求データを起こします。このシステムでは変動項目となる電気代・水道代等は管理しません。

家賃管理パターン4(メニュー)
家賃管理パターン4(メニュー)

家賃管理パターン4(入居者入力)
家賃管理パターン4(入居者入力)

家賃管理パターン4(入金入力)
家賃管理パターン4(入金入力)

関連記事

テーマ : データベース
ジャンル : コンピュータ

オートフォームで作ったものを直す

  ACCESSのオートフォーム機能で作成したものを以下に示します。具体的な作成手順は他の解説本等を参考にして下さい。

生徒名簿フォーム
生徒名簿フォーム 

家族フォーム
家族フォーム

 レイアウト的なものは好みもありますし、ここでは考察の対象にはしませんが、例えばホームページのデザインと違って業務システムで必要とするデザイン性とは見た目云々よりも操作性に焦点を当てたユーザーインターフェースを重視します。時には人間工学的な要素を取り入れ、入力しやすく、間違いにくく、見やすく、疲れにくく、パフォーマンスを重視したものになります。むしろ地味で凡庸で落ち着いた感じが望ましく、ホームページやチラシのように派手で人目につくデザインとは好対照をなす場合があります。

 展示会でのデモ用とか店頭でのディスプレイ用に派手な色合いにするケースもありますが、日常的に長年使う事を目的にした業務システムでの入力画面というものは色合いなどは素っ気ないくらいで丁度いいと思います。

 配置としては自然な目線の流れに沿ったつまり左から右、上から下へが基本です。そしてフォーカスの飛び方も見えている並びに沿って飛ぶのが望ましいです。

 オートフォームで出来上がったレイアウト配置は結構うまく出来ていると思います。テキスト型の長さに応じてテキストボックスの長さが決定されていますし、住所等長いものは2段になっています。ラベルとテキストボックスの長さのバランスもよく、幅は一番長いものに合わせてあって見た目も綺麗になっています。

 画面領域を節約するという意味では必ずしもテキストボックスではテキスト型の長さ分の幅を取らなくとも大丈夫です。横にスクロールして入力できますので。ただ人間の心理上(紙に記入する感覚が残っている人も多いので)、入力出来る領域分幅が取られている方が安心できます。又、表示された時にもカーソルをスクロールして見えるとはいえ、全体が最初から見えた方が親切です。領域が許す限り幅はたっぷり取りましょう。

 とりあえずデザインはこのまま踏襲して次回では機能面での検討に入ります。項目によってはテキストボックスでなく、コンボボックスやチェックボックスの方が適切なので、その検討も次回以降に考えます。
 
関連記事

テーマ : データベース
ジャンル : コンピュータ

最新記事
全記事表示リンク

全ての記事を表示する

月別アーカイブ
カテゴリ
お問い合わせ
まずはこちらのフォームより御一報下さい。

名前:
メール:
件名:
本文:

検索フォーム
RSSリンクの表示
アクセスランキング
[ジャンルランキング]
コンピュータ
478位
アクセスランキングを見る>>

[サブジャンルランキング]
ソフトウェア
64位
アクセスランキングを見る>>
ブログランキング

FC2Blog Ranking

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。