登録／キャンセルボタンについて

１．はじめに

FileMakerは、データが自動保存されるため、登録ボタン、キャンセルボタンのついた以下のような画面の処理はできない。

図１．登録・キャンセルボタンのある画面

今まで、数十年ソフトウェア開発の現場にいて、これは何とも解せないことでした。

以前、FileMaker9で開発作業を行っていたころ、他言語でできるたこの機能をどのように実現するかについていくつかの試みを行いました。

そのなかの1つの方法として、以下の方法があります。

〇画面上で編集したいレコードに、で編集するフィールドの代わりになるグローバルフィールドフィールドをフィールド数用意し、画面の編集フィールドにはそれらのフィールドを割り当てる。（前提）

①編集画面に遷移する際、編集したいレコードの各フィールドの値をグローバルフィールドに代入する。

②（編集はグローバルフィールドを操作する。）

③【登録】ボタンが押されたとき：グローバルフィールドの値を編集対象のフィールドに代入し、画面を遷移する。
【キャンセル】ボタンが押されたとき：何もせずに画面を遷移する。

このような方法で、なんとか、当時普通と思っていた機能を実現しました。
多くの余分なグローバルフィールドと、余分な値の代入のスクリプトを使い、よりプログラムを煩雑に、修正作業を面倒にしていました。

２．Filemakerはレコードを自動保存するの？

皆さんは、「FileMakerはレコードを自動保存する」と思っていますか？
実は、それは違います。「レコードを自動保存する前に、メッセージボックスを表示し保存するか確認する機能」があります。
画面ごとに、レイアウト設定の「一般」タグの「レコードの変更を自動的に保存する」のチェックボックスへのチェックの有無で自動保存か否かの設定を制御できます。

図２．レイアウト設定（一般）画面

では、チェックをしないとどうなるかというと、更新するタイミングで以下のようなメッセージボックスを表示します。

図３．レコード変更の確認のメッセージボックス

この機能を利用すれば、「登録」「キャンセル」ボタンなしにそれらの機能に対応できるのではと思ったのですが・・・。落とし穴がありました。
図1の画面で、ボタンでも入力フィールドでもない部分をクリックしたら、このメッセージボックスが出るのです。FileMakerではフィールド以外の場所をクリックするとレコードの更新をしようとするのです。
これでは、このメッセージボックスの表示で対応するのは中途半端です。

３．データ更新とスクリプトトリガ

ということで、じゃあと次を考えたことが、スクリプトトリガのことです。

レイアウトのスクリプトトリガにOnRecordCommitがあります。これは、変更されたレコードが確定される前にスクリプトを実行することができるスクリプトトリガです。
更新時に図３のメッセージボックスが出る設定にしておいて、OnRecordCommitでボタンを押されたかどうかを判断して、ボタンでも入力フィールドでもない部分をクリックされた場合は、更新処理を行わないようにすればそれで、前章の問題が解決するのではないかと考え以下の処理を組み込みました。

①「ダイアログ表示」という、メッセージボックス出力するスクリプトを作成する。

②スクリプトトリガOnRecordCommitに「ダイアログ表示」を割り当てる。

図４．スクリプトトリガの設定

このようにして、システムで出力する更新確認のメッセージボックスの前に、スクリプトトリガに割り当てる「ダイアログ表示」の方が先に動く（スクリプトで設定したメッセージボックスの方が先に表示する）ことを確認したところ、意に反し、システムで出力する更新確認の方が先に表示してしまいました。

以上のことから、「レコードの変更を自動的に保存する」にチェックをした状態で、OnRecordCommitを利用することでの対応について考えてみました。

４．フラグとスクリプトトリガを利用する処理

OnRecordCommitというスクリプトトリガは、トリガされたスクリプトが、結果としてTrueを返すと更新を実施し、Falseを返すと更新を行いません。また、レコードの変更がない場合はトリガ処理に行きません。

例えば、図1の画面で、

①「状態チェック」という、スクリプトを作成し、フラグの値が１ならばFalseを返し、０ならばTrueを返す機能を組み込む。

②スクリプトトリガOnRecomitに「状態チェック」を割り当てる。

③編集画面に遷移する際、フラグに１をセットする。

④【登録】ボタンが押されたとき：フラグに０をセットし、画面を遷移する。
【キャンセル】ボタンが押されたとき：レコードを復帰し、フラグに０をセットし、画面を遷移する。

これで、編集中はフラグが１なので更新は行わず、登録ボタンが押されたときだけ更新され、キャンセルボタンが押されたときは編集前の状態に戻ります。

５．まとめ

上記の処理は、画面中にポータルがあった場合などの配慮が十分ではないかもしれませんが、基本的には問題ないと思われます。
しかし、このような【登録】【キャンセル】のある画面が必要なのでしょうか。

・不特定多数の人が使用する。

・複数のテーブルにわたる編集処理が１画面でおこなわれ、更新タイミングによってはテーブル間の整合性が取れなくなる。

等の理由で、必要な場合もあるとは思います。しかしながら、通常の場合はFileMakerの標準機能を使った更新処理で問題ないと考えます。

より生産性の高い、簡単に作成できるというFileMakerの特徴を十分に生かしたプログラム作成を推進していくのが望ましいと考えるのは私だけではないと思います。

2016.9.22　Sage

本記事は、FileMaker_Zakkaより転載しました。