4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

FileMakerAdvent Calendar 2022

Day 1

【FileMaker】「なんにもしてないのにリストで表示していたデータが違うんです」「それ、なんかしてます」

Last updated at Posted at 2022-11-30

ユーザが「なんにもしてないのに」というのは「何かしているけれど気づいていない」ということだということに気がついている開発者は多いと思います。
開発者同士でも実はあって、「なんかリストでさっき触ってたデータと違うのが表示されるの、なんでかわからないけど行っちゃうのをなんとかしたいんです」という「なん」が多い会話で「あぁ、なんかやってるんだな、、、」もしくは「あぁ、あの処理がなんか足りてないんだな、、、」と思ったりします。

前置きが長くなりましたが、今回は、そんな「なんにもしてないのに、、、」という言葉でよく聞く、

「なんにもしてないのにリストで表示していたデータが違うんです」

というお題の解決策を紹介したいと思います。

サンプル作成環境

今回のサンプルは、FileMaker Pro 19.5.4.401環境で作成しました。
使用している関数等は下位バージョンでも動くと想定していますが、保証はしません。

現象

こういう現象を、今回考えます。
1.郵便番号データの"90401030"沖縄県中頭郡北谷町桑江のデータを参照していたとします。
スクリーンショット 2022-11-27 16.31.15.png

2.その後、何かの処理やボタンで別レイアウトへ移動して同じTO(テーブルオカレンス)で別データなどの処理をします。
今回は山形県のデータをごにょごにょしました。
スクリーンショット 2022-11-27 17.15.00.png

3.そして、元の郵便番号データに戻ると、レコード位置がさっき見ていたデータと違う、、、
スクリーンショット 2022-11-27 17.05.32.png

レイアウト戻ったときには、その前に参照していたところに戻りたいのに、、、

何か実装をしていた?

ここで、レイアウトの情報を見てみましょう。
レイアウトが表示されるときに、onLayoutEnterスクリプトトリガで何かスクリプトを実行しています。
スクリーンショット 2022-11-27 17.07.04.png

スクリプトを見ると、何かいろんな処理の後、確かに最初のレコードに移動をしています。
スクリーンショット 2022-11-27 17.06.55.png

原因

この、レコードの移動をしてしまうのは、以下の原因が考えられます。

・レイアウトがリストだったりポータルを実装していると「なんとなく」実装してしまう
・単純に「最初の」を正しいレコード位置に戻してあげていない
・共通のスクリプトにしていて、別のボタンなどをクリックしたときにはレコードの最初に戻る必要があった

「なんとなく」って、、、まさかと思うのですが、サンプルをコピペして実装している場合は、案外こういう原因だったりします。
あとの2つは割とスクリプトデバッガを使うことで解決できることが多いです。

その他、今回のサンプルで最大の考慮すべき点は、2つのレイアウトで同じTO(テーブルオカレンス)を表示していることになります。

気をつけること

では、こういう意図しない動きにしないために、気をつけることを3つ挙げます。

その1:スクリプトデバッガを使って確認する

スクリプトを実装したときは、「動く」と思ってスクリプトデバッガを使わずにそのままスクリプトを動かしがちですが、自分の心に「待った」をかけましょう。
「これくらいの処理は間違えない」と思っているときにこそ、スクリプトデバッガをまず最初に使って動作を一つずつ確認して、意図した動作になっているか確認してからスクリプトを動かしましょう。

その2:ユーティリティ化するときに余計な処理を入れない

今回のサンプルでは単純にonLayoutEnterスクリプトトリガ用にスクリプトを作成して実装していますので間違えにくいのですが、ユーティリティ化していたり、複数のボタンやスクリプトからキックされるスクリプトの場合は、その時々の状況でレイアウト移動が必要だったり必要なかったりしますので、ユーティリティ化している時こそレコードの移動を含まずに実装し、個別にキックされるスクリプト内でユーティリティスクリプトが返ってきてからレコードの移動など固有の動きを実装することをお勧めします。

その3:別レイアウトでレコードを表示するとき同じTOでいいのか一旦立ち止まって考える

TOを増やしたくないばかりに同じTOを使い回すことがあると思います。
別TOすることでこうしたレコード位置の問題を考えなくてもいい場面もありますので、同じTOを別レイアウトで使い続ける必要があるのかを設計の段階で考えてみましょう。

修正

では、今回の場合はどうすれば元のレコード位置に戻れるでしょうか?
修正してみましょう。

修正方法案1:レイアウトを離れるときに元のレコード番号を記録しておく

これが一番簡易的な方法だと思います。
グローバル変数に今いるレコード番号をセットしておきます。
スクリーンショット 2022-11-27 17.09.43.png
onLayoutExitスクリプトトリガに、このスクリプトを指定します。
スクリーンショット 2022-11-27 17.10.01.png

レイアウトに戻ったときには、onLayoutEnterで指定したスクリプトが動くので、このスクリプトで移動する際にグローバル変数にバックアップしていたアクティブレコード番号まで移動します。
スクリーンショット 2022-11-27 17.09.35.png

メリット・デメリット

この修正方法案1のメリット・デメリットを挙げます。

メリット
レコード位置をわざわざ計算する必要がない
デメリット
あくまでもそのレイアウト(TO)でのアクティブレコード番号なので、レコードの順番が変わったときに対応できない

修正方法案2:レイアウトを離れるときに元のレコード主キーを記録しておく

修正方法案1に似ていますが、データの操作をする中で、レコードの追加・削除やソートをしていたり、、、とレイアウト内でのレコード番号が変わる場合があります。
そんな時は、FileMakerの新規レコードで自動で作成される主キーをアクティブレコード番号の代わりにグローバル変数にセットしておき、元のレイアウトに戻るときに検索をして表示をする、という方法もあります。

スクリーンショット 2022-11-27 17.58.18.png
スクリーンショット 2022-11-27 17.58.30.png

この時、元いたレコードをバックアップしていたグローバル変数は最後にクリアしておくことをお忘れなく。
そうしないとファイルを開いている間、このレイアウトに切り替えるたびにレコードの検索をしてしまい、意図しないレコードへ飛んでしまます。。。

メリット・デメリット

この修正方法案2のメリット・デメリットを挙げます。

メリット
主キーを実装しておくだけでレイアウト(TO)のアクティブレコード位置に惑わされない
デメリット
検索して移動する場合、マシンの性能やホストの負荷などで検索時間に時間がかかることがある

修正後の動作を確認する

では、修正をしたスクリプトを確認してみましょう。

修正方法案1

他のレコードに何も操作がない場合

今回は、長崎県の"8540067"長崎県諫早市久山台レコードを表示していたときに、別レイアウトで同一TOを表示し、何かしら別レコードを編集して戻る、という動作になります。

長崎県の"8540067"長崎県諫早市久山台レコードを表示し、、、
スクリーンショット 2022-11-27 18.01.19.png

レイアウト切り替えで別レコードを編集
スクリーンショット 2022-11-27 18.01.33.png

元のレイアウトに戻る
スクリーンショット 2022-11-27 18.01.41.png

元の"8540067"長崎県諫早市久山台レコード位置に戻れましたね!

他のレコードが削除された場合

では次に編集中のレコードよりも上位にあるレコードが削除されたケースで、この修正方法案1がどう動くかをみていきます。
ただいま、郵便番号"9160427"の福井県丹生郡越前町六呂師のレコードを表示しています。
スクリーンショット 2022-11-28 10.53.07.png

この状態で同じTOのレイアウトに切り替えて、上に並んでいるレコードを削除します。
スクリーンショット 2022-11-28 10.53.38.png

そして、元のレイアウトに戻ると、レコード位置が郵便番号"9160427"の福井県丹生郡越前町六呂師ではなく、その下に移動してしまいました。
残念!
スクリーンショット 2022-11-28 10.53.50.png

これは、削除以外にも、ソートやポータル表示で条件によって表示・非表示を設定している場合も起こりうることです。

修正方法案2

では、主キーをバックアップしていた場合の修正の動作を確認しましょう。

他のレコードに何も操作がない場合

修正方法案1と同様、"8540067"長崎県諫早市久山台レコードでチェックしてみましょう。
スクリーンショット 2022-11-28 11.09.45.png

この状態で同じTOのレイアウトに切り替えて、他のデータの編集をします。
スクリーンショット 2022-11-28 11.11.37.png

そして、元のレイアウトに戻ります。
スクリーンショット 2022-11-28 11.10.14.png

戻ってますね!

他のレコードが削除された場合

レコードは、郵便番号"9160427"の福井県丹生郡越前町六呂師を差しています。
スクリーンショット 2022-11-28 11.03.17.png

同じTOのレイアウトへ切り替えて、修正方法案1のように上に並んでいるレコードを削除します。
スクリーンショット 2022-11-28 11.03.33.png

ちゃんとレコード位置が郵便番号"9160427"の福井県丹生郡越前町六呂師を差していますね!
スクリーンショット 2022-11-28 11.03.39.png

他のアイディア

他に思いつくものとして、いくつか挙げてみます。
・TOをレイアウトや機能ごとに用意する
・レイアウト切り替えを新規ウインドウで実装し、戻るときには新規で出したウインドウをクローズする
・リレーションシップグラフで検索をせずに表示する

別TOを用意する方法は、一見簡単に見えますが、TOが変わることでもしかしたらスクリプトやレイアウトの表示設定を修正しなければならなくなるかもしれませんので、慎重に進めた方がいいです。
新規ウインドウで実装するのも、一画面で済ませなければならない現場では不都合があったりします。時と場合によりますね。
リレーションシップグラフを活用するのは、FileMakerのリレーションシップグラフの理解度があまりない方にはすごくハードルが高く思えるので、まずは自分が知っているスキルで解決してみましょう。

これは、開発する方やスキルによって難易度ややりやすい方法などがあったりすると思います。
また、修正方法案でも挙げたように、修正する案のメリット・デメリットを理解した上で修正をするのも大事だと思います。
データ数が多くなってくるごとになんか動きが遅い、、、など、別の「なんか」が出てくるかもしれません。。。

ただ遠い将来を憂うよりも、まずはちょっと先の未来を見据えて修正してスパイラルにいいものに仕上げていく方法がFileMakerには合っていると思います。
ということで、今回は、TOを変えずになんとか前回操作していたレコードに戻る方法を2つご紹介しました。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?