このメソッドは 3 種類の引数を受け取ります。

• それぞれのキーワード引数は、"name=value" というフォームで、新しく作成されるオブジェクトのオプション name に value を設定するように指定します。
• タイプが EventHandler (通常は on を使用して作成) である各ダイナミック イベント ハンドラ指定では、新しく作成されるオブジェクトに追加されるダイナミック イベント ハンドラを指定します。
• 他の任意の引数は Visual にキャストされ、テキスト (または適切な場合はインライン Graphic) として追加されます。

このオプションは、Curl グラフィック システム内での通信のために使用されます。これは、ユーザー コードで不用意に設定や設定解除を行わないでください。また、通常は、ユーザー コードで直接読み取るべきではありません。現在の DisplayContext が必要な場合は、Visual.get-display-context を呼び出すことによりフェッチしてください。

画面上のウィンドウまたは印刷されたページで表示可能なすべてのグラフィック階層は、そのルートにおいて、display-context オプションを DisplayContext オブジェクトに設定するオブジェクトを持つ必要があります。このオブジェクトは、グラフィック階層の表示に使用される表示媒体に適しています。つまり、オブジェクトは、display-context オプションの値が null から非 null DisplayContext オブジェクトに変更されるのをモニタリングすることにより、表示不可能なグラフィック階層に連結されていることを認識します。したがって、特定の動作を実行する必要のある Visual のサブクラスは、表示不可能なグラフィック階層に接続された場合、次のようなオプション宣言を含むことにより display-context オプションをモニタリングします。

{nonlocal-option public display-context:#DisplayContext
change handler}

ここで、change handler 内のコードは display-context オプションの現在値 (変数 display-context の値として、変更ハンドラ内にある) を取得し、null および非 null の値の間で行われる変更をモニタリングし、必要とされる動作を実行します。

ただし、このプログラミング熟語を使用するプログラマーは、グラフィカル表示を再配列する際、グラフィック階層からグラフィカル オブジェクトを一時的に分離し、これらを同じ階層に再アタッチすることが、割に一般的であることを理解するべきです。この処理により、一時的に分離されたオブジェクトは、display-context オブジェクトが null になり、再び非 null になるのを観察します。display-context オプションでの変更をモニタリングするコードは、この可能性を考慮に入れ、この状況における望ましくない動作の実行を回避しなくてはなりません。

この値が LayoutContext.epoch より大きい場合は、レイアウト処理中にレイアウト要求が行われたことを意味します。レイアウト処理が再実行されることになるので、この値を使用して、進行中の処理を完了前に停止することができます。get-layout-epoch も参照してください。

既定の実装は、-1 を返します。これは、レイアウトが再実行されるかどうかを無視することを示します。サブクラスでエポックをキャッシュする場合は、TextFlowBox.propagate-request-layout をオーバーライドし、キャッシュされた値をここで返します。

返されたプロシージャは、各オプション子（またはその子孫）が興味を持つ、各非ローカルオプションに対して１回呼び出されます。オプション キーが、このプロシージャを介して登録されていない場合は、オプション値が変更する場合に、このオブジェクトは子孫に対し、（子孫がこのオプションに関心を示していないため）変更ハンドラを呼び出す必要はありません。

特に、返された値が null でない場合は、このオブジェクトが新しいオプション子を入手すると OptionListInterface.change-option-parent-notify がそれを呼び出します。

既定では、返されたプロシージャは、そのオプション親に登録を転送します。

まれですが、典型的には、オプションの伝搬メカニズムをオーバーライドするオブジェクトのみにより、オーバーライドされます。

これらの OptionKey の Array-of。

既定の実装 OptionListInterface.registered-option-keys は、このオブジェクトで OptionListInterface.register-options を呼び出し、その結果得られるオプション キーのセットを収集し、リストとして返します。これはシンプルで正確な方法ですが、あまり効率的ではない場合があります。したがって、サブクラスでもその register-options の実装が非常に複雑な場合は、この既定の実装を使用しないように推奨されます。代わりに、このようなサブクラスでは register-options 呼び出しの結果をリストとしてキャッシュし、このリストを返すだけのメソッドで OptionListInterface.registered-option-keys をオーバーライドする必要があります。

obj: 追加するオブジェクト。追加される前に Visual に強制変換されます。

このメソッドは、2 つのオプション キーワード引数も受け取ります。ただし、どちらか 1 つしか指定できません。どちらも指定されていない場合、新しい子は BasicTextFlowBox に最後のオブジェクトとして追加されます。

• before=sibling は、obj を sibling の位置の直前に追加することを示します。
• after=sibling は、obj を sibling の位置の直後に追加することを示します。

指定する sibling は、TextFlowBox のトップレベルの直接の子でなければなりません (このメソッドで追加された子などがこれにあたります)。

(Visual に強制変換された後) 追加されたオブジェクト。

obj がもともと Visual だった場合は、それまで置かれていた場所から自動的に削除されます。

強制変換が行われる場合は、次の規則に従います。

• NULL は無視されます。
• Visual はそのまま使用されます。
• Dynamic は Visual に変換されます。
• String は、内容が String の Visual に変換されます。
• オブジェクトに to-Visual メソッドがある場合は、それが呼び出されます。
• それ以外のすべての場合は、オブジェクトで format が呼び出され、結果の String が Visual に変換されて追加されます。

子の追加にさらに別の処理を関連付けることができるように、BasicTextFlowBox のサブクラスでオーバーライドできます。この種のオーバーライド メソッドは、以下を呼び出す必要があります。

{super.add obj, ...}

これで、BasicTextFlowBox 自体の追加アクションを呼び出して、提供された任意のキーワード引数を渡します。

BasicTextFlowBox に何かを追加しても、パラグラフ、行、または語の境界が自動的に挿入されることは意味しません。

ボタンを押してテキストを末尾に追加します。

例: TextFlowBoxにテキストを追加
{value let tfb:TextFlowBox = {TextFlowBox width = 5cm, height = 6cm, border-color = "black", border-width = .05cm, "Initial content" } let addme:CommandButton = {CommandButton label="Add more content", {on Action do {tfb.add "and more"} } } {VBox tfb, addme } }

既定の実装はエラーをスローします。クローン化機能を提供するクラスは、 を返すためには、このゲッターをオーバーライドする必要があります。

item: 追加または削除されたバインディング オプション。

removed?: item が削除された場合は true、それ以外の場合は false。

既定の実装 OptionListInterface.notify-option-children では、何も行われません。サブクラスではこのメソッドをオーバーライドして、このオブジェクトの各オプションの子 c に対して {c.option-propagate-notify item removed? } を呼び出すようにする必要があります。

x, y: ポイントの座標です。

このポイントをカバーする EventForwarder 子孫、あるいはそのような子孫が存在しない場合は NULL です。

このメソッドは、PointerEvent を転送する場合やその他の類似の状況で使用されます。

他の Box は、通常このメソッドから Graphic を返しますが、TextFlowBox は返しません。

サブクラスは、上記の指定に適合する様式で、このメソッドを実装しなければなりません。

epoch: このレイアウト無効化に関連付けられている Layout Epoch。これは、通常、get-layout-epoch を使用して得られる現在の Layout Epoch です。

一般的に、このメソッドは、Box.request-layout から Box の親にレイアウトの要求を伝えるために呼び出されるか、Layout.request-layout から呼び出されます。

Box でこのメソッドを呼び出すことは、Box のグラフィカルな子孫のいずれかが新しいレイアウト ネゴシエーションを要求していることを示します。この状況は、Box での Box.request-layout の呼び出しとは対照的です。この場合は、Box 自体が新しいレイアウト ネゴシエーションを要求していることを意味します。これらの 2 つの別個のメソッドが提供されるのは、その後のレイアウト ネゴシエーションの初めに Graphic.attempt-revalidate-layout が呼び出されるときに、異なるアクションを保証するためです。Box.propagate-request-layout の呼び出しによって、この Box にレイアウト要求が通知された場合は、Box 自体では何も変更されていないので、Box の子で Graphic.attempt-revalidate-layout メソッドが呼び出されたときにすべての子の答えが true であれば、Box の Graphic.attempt-revalidate-layout に対する答えは常に true になります。しかし、Box.request-layout が呼び出された場合は、Box は、そのすべての子のレイアウトについて有効性を再検証できたとしても、それ自体のレイアウトが有効とは認められない場合があります。これは、グラフィカルな子の追加や削除、またはそれらの子の空白や配列での変更など、Box 自体の構造で変更が加えられている可能性があるからです。

このメソッドは、情報を保持してレイアウト無効化を追跡する Box サブクラスでオーバーライドできます。このようなオーバーライド メソッドにはすべて super.propagate-request-layout の呼び出しが必要です。このメソッドは、グラフィック階層のルートになるように設計されている View などのクラスでもオーバーライドされます。この場合、レイアウト要求を記録し、新しいレイアウト ネゴシエーションに合わせて整列させるコードによってメソッドがオーバーライドされます。

p: 引数として OptionKey を使用して呼び出せるプロシージャ。

このメソッドは、オブジェクトがモニタしているオプション キーを確認する必要がある場合に任意のコード内で呼び出されます。このメソッドは、プロシージャ p をまったく呼び出さないかまたは何回か呼び出し、呼び出すたびに引数として OptionKey を渡す必要があります。このオブジェクトによりモニタリングされるオプション キーのセットは、p のすべての呼び出しで指定されたオプション キー セットの連結であると見なされます。p を複数回呼び出せるという能力を利用して、オプション親はモニタの対象となるオプション キーのリストを指定して p を一度呼び出し、次に、同じ引数 p を与えてオプションの子それぞれの register-options メソッドを呼び出し、このメソッドの目的を果たすことができます。この方法はシンプルですが、ほとんどの場合は、オプション親がその子における register-options 呼び出しの結果をキャッシュして、親の register-options メソッドが呼び出されたときにそのリストを提供する方がより効率的です。ローカル バインディング オプションへの変更通知は、それらのキーが登録されていない場合でも行われます。

要求は、このオブジェクトのグラフィック階層のルートに到達するまでグラフィカルな祖先のチェイン上を転送されていきます。このルートが View で、ポインタがその View 内にある場合、PointerNonevent を含む PointerEnvelopeEvent が発生し、必要な PointerCrossing イベントの生成を引き起こします。

ポイント (x,y) を含む子オブジェクトの識別に (x,y) の位置をマップする、キャッシュされた状態を格納する SequenceBox のようなサブクラスによってオーバーライドできます。こうした状態はリセットして、グラフィック階層のオブジェクトの幾何形状が変更されても新しい PointerEnvelopeEvent が適切に送信されるようにします。このメソッドをオーバーライドする場合、オーバーライド メソッドには以下の呼び出しを含めます。

{super.request-pointer-trace}