the row an open list has highlighted, which is what a confirm would take
the selected entry; the first enabled one when nothing was selected, null when empty
closes the list without taking anything, the escape key's own action
takes the highlighted row: closes, selects it, and fires onChange when it moved
moves the highlight by delta rows, skipping disabled entries and wrapping at both ends
opens the list, restoring the highlight to the current selection
Opens the list and highlights index, if it is enabled, so setHighlight(i) then
confirm() is a whole programmatic pick. While already open it only moves the
highlight; a disabled dropdown does not open.
A closed button that opens a list of options - the "option button" a settings row or a scenario picker drops down.
This is the model only;
DropdownViewis the ready-made widget over it. A game with its own look drives the model directly withopen/move/confirmandonChange.Renderer-free, like
TabbedList: the state is the whole widget's mind, and a game draws the button's label and the open list wherever its own layout wants them. The rule worth naming is that opening restores the highlight to the current selection, so the first arrow key does not jump from wherever the highlight was last, and a disabled option is skipped by the highlight exactly asListViewskips one.Example