IRowPool

Remarks

The seam between composition and a virtualizing control, and it exists because the dependency only goes one way. VirtualizingPanel and VirtualizingGrid live in Vixen.Ui.Controls, which references Vixen.Ui; so BuildContext cannot name either of them, and until something in this assembly described what they do, the only way to fill one was to write CreateRow/BindRow by hand in C#. That is what #758 is about.

⚠ Four members, and the shape of them is the whole argument for why a pooled list is not a @for. A loop is told a sequence and keys; this is told a count, asked for slots when it runs short of them, and then tells a slot which index it is showing now. A slot is not an identity — the pool only ever grows, and a row that was line 4 is line 900 after a scroll — so every rule the keyed reconciler teaches is false here: nothing survives, nothing is matched, and the body is built once per slot rather than once per item.

⚠ It is the control's own contract restated, not a new one. The two delegates are the ones the controls already had, with the control's own type taken out of CreateRow so that this assembly can name it; RowHost is what CreateRow used to reach through the panel to get at. Nothing about how a row is measured, parked or positioned is here, because none of it is composition's business.

⚠ Two implementations, and their own names for the same members differ. VirtualizingPanel calls a slot a row and VirtualizingGrid calls it a tile, so both implement this explicitly rather than renaming what every caller already uses — and one BuildContext.Pool fills either, which is the whole of what the seam buys.

⚠ Shipped ahead of its callers, and it has three now, one per half. MessageLogView.vxml and ConsoleView.vxml fill their VirtualizingPanels through this seam with an @rows block, which the markup compiler turns into BuildContext.Pool (#758), and AssetGrid.vxml fills the editor's one VirtualizingGrid the same way (#1406). No editor panel fills a virtualised list from C# any more — but ⚠ one control still does: TreeView sets its own VirtualizingPanel's CreateRow/BindRow in OnCreated, over a typed TreeRow part, and the editor's Hierarchy and Project trees are built on it. That is a control's implementation rather than a panel's template, so it is outside #758's reach, not an oversight in it. Recorded here rather than left to a grep, because "a finished thing nothing calls" is this repository's commonest defect and a reader is owed the callers before concluding anything about the seam.

Fields and properties (4)

• int RowCount

  How many items there are.

• UiElement RowHost

  Where a row element belongs. A slot made anywhere else is not in the list.

• Func<UiElement>? CreateRow

  Makes one pool slot. Called only when the pool has to grow.

• Action<UiElement, int>? BindRow

  Tells a slot which item it is showing now. Called on every realise, not only on a change.

Used by (4)

• BuildContextVixen.Ui
• EmitterTestsVixen.Ui.Markup.Tests
• VirtualizingGridVixen.Ui.Controls
• VirtualizingPanelVixen.Ui.Controls