FileMakerでファイルを作るときにいつも必ず使う小ネタ・小技があります。今回はウインドウサイズの話題です。
このページ内の見出し
最適化
昔Macに「ウインドウ最適化ボタン」というスマートかつエレガントなボタンがありました。
最適化ボタンは緑ボタンに引き継がれましたが、その後「最大化」に落ちぶれ、やがてフルスクリーン化という酷い最後を遂げました。今でも最適化機能はかろうじて残っていて、タイトルバーのダブルクリックがそれです。アプリによりますが下品に最大化されてしまったりエレガントに最適化されたりします。
FileMakerのスクリプトステップに同じ機能あります。「ウインドウの調整」の「収まるようにサイズ変更」がそれです。
基本的にレイアウトモードで作成したサイズがデフォルトとして「収まるサイズ」になります。これを割り当てたボタンをレイアウト上に配置することもあるし、レイアウトが表示されたときに発動するトリガー（OnLayoutEnter）に仕込むことも多いのです。
ただし、トリガー（OnLayoutEnter）に仕込むときには「収まるようにサイズ変更」の1行だけでは上手くないです。ちょっと工夫します。
今回はこの件についてですが、そもそもウインドウサイズを最適化することに興味なければどうでもいい話題でございます。
FileMaker で最適化すること
収まるようにサイズ変更
表示形式によって最適化の挙動は異なります。
通常フォーム形式の場合はレイアウトで定めたサイズ、リスト形式や表形式では縦が画面いっぱいになります。
画面の小さなノートタイプでは気になりませんが、デスクトップでは縦いっぱいになるのが大きすぎると感じることが多いので、縦サイズを制限したくなります。
ウインドウの移動/サイズ変更
そこで、一度「収まるようにサイズ変更」してから、続けてウインドウサイズを調整します。ウインドウの移動/サイズ変更です。
スクリプトの流れはこうですね。表示形式によって変えます。
ウインドウの調整[ 収まるようにサイズ変更 ] if [ Get (レイアウト表示状態) = 0 ] #通常フォーム else if [ Get (レイアウト表示状態) = 1 ] #リスト else if [ Get (レイアウト表示状態) = 2 ] #表 end if
ここで注意すべきポイントは表示形式で条件分岐してるのに関数が「表示状態」なところです。→ FileMaker ウインドウに関する忘れがちな用語のまとめ – 表示方法・表示形式・表示状態
高さを制限
ウインドウの移動/サイズ変更では高さを制限したいと思います。
個人的な感覚にすぎませんが、リスト表示では1100pxくらいに収まってくれると見やすいなと思ったりしますので
if ( Get ( ウインドウ高さ ) > 1100 )
ウインドウの移動/サイズ変更 [現在のウインドウ ; 1100 ]こんな感じで制限掛けてます。これを、上記の条件のリストと表にあてがいます。高さいっぱいに広がることに抵抗ある人も少ないと思いますが。
トリガーOnLayoutEnterに仕込む
レイアウトを切り替えたときにキリッとウインドウサイズを最適化したいのでトリガーOnLayoutEnterに仕込んでいるんですよ。ですのでレイアウトが切り替わる度にウインドウが調整されます。
それでいいのですが、フォーム表示の場合はウインドウサイズを手動で広げることもよくあります。行って帰ってきたときに最適化されたくない。そこで、さらに工夫をします。
ウインドウサイズを動かしたときにそれを保存し、次のレイアウトエンターで再現するのです。
フォームのとき
ウインドウサイズを記憶する
手動でウインドウサイズを動かしたとき、それを記録します。スクリプトトリガに OnLayoutSizeChangeありますね。サイズを変えたら発動します。完璧に想定済みなのでございますね。
ウインドウサイズと位置を記憶するスクリプトを一つ作りましょう。順序よく判りやすく書くとこうです。
変数に幅をゲット。
変数に高さをゲット。
変数に上位置をゲット。変数に左位置をゲット。
グローバル変数「$$レイアウト名 & ウインドウ」にその値として、4つの値を改行で繋げたものを作る。
位置までは要らないんですけど、いるときのために一応書いときました。
もう一つ、最後に変数名「$$レイアウト名 & ウインドウ」という不穏な言葉が出ましたが、これはグローバル変数の名前を「レイアウト名 ウインドウ」とすることで、どのレイアウトの変数なのかを明確にします。
えっ。変数の名前を計算で作ることなんて出来るのか？はいできます。
余談：変数名を計算式で作るの巻
・・・と、ここに書き始めましたがまたまた長くなって余談の域を逸脱したのでポストを分けました。変数名を計算で作ることに興味のある方はこちらの投稿を参照ください。
ということでウインドウを手動で変更させたときに、グローバル変数「$$レイアウト名+ウインドウ」にサイズが記憶されることになりました。
いえ、別にわざわざ変数を名前で設定せずとも、レイアウト名を含めた変数を手動で作ればいいんですけど。いろいろ面倒なことになるのでね、変数を名前で設定できれば便利かなと。
ウインドウサイズを再現する
OnLayoutEnterトリガーに仕込む最初の条件分岐がありました。
ウインドウの調整[ 収まるようにサイズ変更 ] if [ Get (レイアウト表示状態) = 0 ] #通常フォーム else if [ Get (レイアウト表示状態) = 1 ] #リスト else if [ Get (レイアウト表示状態) = 2 ] #表 end if
まず1行目の収まるようにサイズ変更を取り払います。すべての場合に最適化するわけに行かなくなりましたから。以下のように一旦変更します。
if [ Get (レイアウト表示状態) = 0 ] #通常フォーム ウインドウの調整[ 収まるようにサイズ変更 ] else if [ Get (レイアウト表示状態) = 1 ] #リスト ウインドウの調整[ 収まるようにサイズ変更 ] ウインドウの移動/サイズ変更 [高さの制限] else if [ Get (レイアウト表示状態) = 2 ] #表 ウインドウの調整[ 収まるようにサイズ変更 ] ウインドウの移動/サイズ変更 [高さの制限] end if
レイアウト表示状態 = 0（通常フォーム） の中を弄ります。グローバル変数「$$レイアウト名+ウインドウ」が存在するかどうかの分岐をさらに設けましょう。
#通常フォーム
if [ IsEmpty ( Evaluate ( "$$" & Get ( レイアウト名 ) & "ウインドウ" ) ) ]
#ウインドウサイズが保存されていないときは最適化
ウインドウの調整[ 収まるようにサイズ変更 ]
else
#保存されているときは再現する
ウインドウの調整[ 現在のウインドウ ;
高さ: GetValue ( Evaluate ( "$$" & Get ( レイアウト名 ) & "ウインドウ" ) ; 2 )
横幅: GetValue ( Evaluate ( "$$" & Get ( レイアウト名 ) & "ウインドウ" ) ; 1 )
]
end ifEvaluate ( “$$” & Get ( レイアウト名 ) & “ウインドウ” ) は、グローバル変数を名前で指定しています。レイアウト名が入っていますから存在の有無が即ち今のレイアウトのウインドウ情報があるかどうか判断できるってことになります。
グローバル変数の値は「幅 ¶ 高さ ¶ …」ですから、幅は1行目、高さが2行目にあります。それぞれ取得してセットしています。
フォームのウインドウ調整 挙動まとめ
手動でウインドウサイズを変えていればグローバル変数に保存されていますからそれを再現します。変えた形跡がなければウインドウの最適化を行います。
以上、フォーム形式のウインドウでした。
別ポストの「変数名を計算式で作る」ことを前提としていますが、フォーム部分、こんな感じで収まりました。
リスト表示のとき
まだ話が続きます。しつこいですね。次はリスト表示です。
リスト表示を使うこともめっきり減りましたがたまに使います。無骨でデータ剥き出し上等の表形式と事なり、リスト表示にはリスト表示なりの美しさの追求というものがあります。
高さ再考
高さについて冒頭で述べました。ウインドウいっぱいにまで縦が広がるのを好ましくなく思っているので高さを制限しましたと。しかしこの記述はちょっといい加減な発言です。
リスト表示にもいろいろあって、レコードがたくさんあるような想定と、すごく少ないレコードの場合では考え方が異なります。レコードが沢山ある場合、それは「ちょっと美しい表形式」という認識だったりします。レコードが少ないってどういうことが考えられるのかというと、ファイルランチャーだとか、値一覧で使用するための限定的なデータを扱うテーブルだとか、カタログ的なデータベースだとかです。
レコードが少ない想定のリスト表示
ここでは、レコードが少ない、あるいは、絞り込み結果のレコードが少ないことが想定されるリスト表示について考えます。
例をあげてみようかしら。
全表示だとそれなりに表っぽくて良いんですが、このファイルは通常フィルターで絞り込んで使うようなタイプなので、下の空白が気になります。
もうひとつもっとわかりやすい例、FMランチャー&修復ユーティリティ（笑）なんですが、レコードは極端に少ないです。
キャプションで書いたとおりなんですが、リスト表示で最適化を行うと真ん中の画像のように縦がびろーんと伸びてしまいます。Finderの最適化では理想の形になります。
FileMakerのマイウインドウサイズ調整スクリプトで理想の形に整えたい。
レコード数に応じたウインドウサイズ調整
凝り始めるとキリがないんですが、どうしたいのかわかりました。レコード数とウインドウ高さを連動させたいんです。
フォームのところでGet(ウインドウ幅)とGet(ウインドウ高さ)を得て再現しましたが、リスト表示ではもうちょい複雑になります。
まず前段階としてFileMakerのパーツの高さを知ります。ツールバー、ヘッダにフッタ、個別パーツの縦サイズをあらかじめ知って（変数にでも）登録しておきます。このために名前やサイズを調べたのさ。→ FileMaker ウインドウに関する忘れがちな用語のまとめ
次に目的レイアウトのボディの高さを調べてこれも（変数にでも）登録します。
何をしているかもうお判りですね。最適化直後のウインドウ高さと、使用可能なスペースの中でレコードボディの高さ×対象レコード数を含むパーツ高さ合計を比較して、大きければ適当に縦サイズを縮めて、小さければボディ高さから見積もった最適サイズまでウインドウを縮めるのです。ツールバーは非表示にすることもありますからそれもチェックして対処します。
まあ、しかしですね、こんなことのためにいろいろゲットしたり変数仕込んだり条件分岐したり、わしあほとちゃいますかねえ。
この例ではリスト表示がひとつしかないので少ない行数で収まっていますが、リスト表示が複数あり、ボディ高さがそれぞれ異なっている場合なんかだとさらに分岐させなければなりません。汎用的に書くなら、パーツ分の数値をもっとちゃんと保存しておき、レイアウトごとのボディ高さを取得して計算式に組み込めばいいと思います。が、リスト表示のボディ高さってゲットできたっけ？できない場合はレイアウトごとに記録しておきますね。
こういったいろんな数値を、変数内でなくフィールドに保存するには、本体テーブルとは別にシステマチックなテーブルを作ってそちらでグローバルフィールドを生産するのが良いと思います。
リスト表示のウインドウ調整 挙動まとめ
ウインドウ高さよりリストされたウインドウ高さが小さければレコード数に応じて縦が縮みます。リストがたくさんあって画面いっぱいになる場合、それでOKならそのまま、縦を縮めたいなら指定した高さに収まります。
以上、リスト表示のウインドウサイズ最適化でした。
さて次は表形式。と言いたいところですが、これは適当でいいです。表形式は無骨さが売りのデータ中心主義で作られます。変な工夫をしないほうがスッキリします。
ということでウインドウサイズの調整についてでした。こんなのはまあ、どうでもいいと言えばどうでもいい話ですが、いや、どうでもよくない。ところでトップで寝そべっているのはとめ22歳、盲目で鼻炎。
