* Add failing unit test for scenario 1 in #11878.
* Set TabOnceActiveElement on realized container.
Fixes scenario 1 in #11878.
* Use TabOnceActiveElement to decide focused element.
Fixes scenario #3 in #11878.
- Renamed `ItemsControlFromItemContaner` in `ItemsControlFromItemContainer'
- Add `ItemsControlFromItemContaner` with attributes `Obsolete` and `EditorBrowsable Never` that call `ItemsControlFromItemContainer`
- Don't make selection follow focus
- Move all keyboard interaction into `ListBox`
- Move all pointer interaction into `ListBoxItem`
- Added `ItemsControl.ItemsControlFromItemContaner` as in WPF
This was signalled for removal in #9553, but I was hesitant to do it because it will be in use by a lot of code in order to override `StyleKey`. Instead of removing it, deprecate it and provide a virtual `StyledElement.StyleKeyOverride` property as the supported way of overriding a control's style key.
Allow overriding the default behavior of item containers in styles or in `ItemContainerTheme`. To do this, use `SetCurrentValue` to set the properties, only if the properties are not already set (i.e. from a style). This also requires us to clear the current value when the container is cleared (styles won't be affected as `AvaloniaObject.ClearValue` only clears local or `SetCurrentValue` values).
Rather than using the `ISelectable` interface to communicate container selection from the `SelectingItemsControl` to the container, use the `SelectingItemsControl.IsSelected` attached property, setting it with `SetCurrentValue` so that bindings defined in a style or item container theme can override the selection. Required an extra virtual `ContainerForItemPreparedOverride` method on `ItemsControl`.
We need to register controls as anchor candidates in the panel instead of in `ItemsControl` because the candidate needs to be registered after arrange. Consider this scenario:
- In Measure:
- Container is realized and registered as an anchor candidate
- Container is unrealized and unregistered
- Container is recycled and registered, but it is still placed in the position from before it was recycled
- In Arrange:
- The container is placed in its new position
- The `ScrollContentPresenter` sees it's been moved and adjusts the viewport to anchor it
This is obviously incorrect, but was what was happening when `ItemsControl` was responsible for registering anchor candidates.
Instead of tracking which containers have already been registered, change the list of anchor candidates in `ScrollContentPresenter` to a `HashSet` so we can just register it multiple times.
- `MenuItem` is a `HeaderedSelectingItemsControl` not a `HeaderedItemsControl` so need to separate logic for that case when preparing items
- Added `HeaderTemplate` to `HeaderedSelectingItemsControl `
- Tweaked logic for selecting header templates: parent's `ItemTemplate` should be used if set (cross-checked with WPF)
- Update menu templates to bind to menu item's `HeaderTemplate`
Fixes#10626Fixes#10718
`ItemsControl` now works more like WPF, in that there are separate `Items` and `ItemsSource` properties. For backwards compatibility `Items` can still be set, though the setter is deprecated. `Items` needed to be changed from `IEnumerable` to `IList` though.
When a `HeaderedItemsControl` is used in an `ItemsControl` it needs to search for an `ITreeDataTemplate` in order to populate the `Items` property. This can't be done properly until it's attached to the logical tree.
Fixes#10398
This necessitated adding another stage to the container preparation lifecycle that will be called after the container is added to the logical and visual trees: `ItemContainerPrepared`. Such a method is going to be necessary anyway if we ever want to expose events for container realization so will probably be worth having regardless.
Steven Kirk
workgroupengineering
Emmanuel Hansen
Max Katz
Steven He
Julien Lebosquain
Steven Kirk
amwx