...
抽象的な記述について知っておきたいこと
カレンダーを移植できるようにするための一環として、ほとんどのスクリプトは「抽象的」なものになっています。そのために、スクリプトでは「Source No X」レイアウトに割り当てられたフィールドが使われています。これにより、すべてのスクリプトですべてのフィールドの参照を編集しなくても、既存のデータテーブルで簡単にカレンダーをポイントできます。
ただし、カレンダーを既存のファイルに統合した後は、抽象的なままにしておく必要はありません。たとえば、イベントのテーブルに「Priority（優先度）」というフィールドがあって、新規イベントを作るときにこのフィールドの値を常に「1」にしたい場合は、通常の「フィールド設定」スクリプトステップを使うだけです。「フィールドを名前で設定」を使う必要はありません。カレンダーを移植する必要がもうなくなっているからです。
（自動入力の計算式で優先度を設定したいとおそらく考えるでしょうが、この解説の意味はご理解いただけるでしょう。）
イベントで使うソースが1つだけの場合は、すべてそのソースにあります。複数のソースを使っている場合には、どのソースがアクティブであるかをテストしてどのフィールドを設定するかなどを知る必要があるでしょう。アクティブなソースは「$$sc_SourceNoLoaded」として記録されます。
変数を理解して使いたい場合は、以下の内容を知っておくと変数の名前がどうなっているかを追跡するのに役立ちます。
イベントを編集するときに使える変数にはどんなものがありますか？
カレンダーの特定のソースを扱うときには、そのソースの実体をグローバル変数にロードします（変数の名前は「$$」で始まります）。特定の変数の名前を知りたい場合、方法が2つあります。
- FileMaker Pro Advancedを使っていれば、「Dev ON」スクリプトを実行し、その後、カレンダーを再描画します。このスクリプトを実行すると、使用中のカレンダーの変数はすべてクリアされずに残るので、SQLクエリ、$sc_iCal変数、イベントのフィールドの割り当てに使われているすべての変数を見ることができます（この方法は、デバッグ全般にも便利です）。
- FileMaker Pro Advancedを使っていない場合は、「Clear Source Variables」スクリプトで使用しているすべての変数のリストを表示します。
さらに、「Load Source Settings at Startup...」スクリプトで、「$$sc_SourceTableOccurenceName」など、選択したソースのテーブルオカレンス名に関する変数をいくつかインポートします。これらは繰り返しによって出現するため、ソース No 2のテーブルオカレンス名は「$$sc_SourceTableOccurenceName[2]」となります。