Add AP to control TabControl Headers behavior #3873
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #3863
This PR adds a new attached property (
materialDesign:TabAssist.HeaderBehavior
) to let consumers decide on how to display the headers of aTabControl
.Currently the headers are always contained inside of a ScrollViewer, which is not always ideal. Under certain circumstances the user is unable to click on "the next" tab, because it is simply not shown:
With the new AP TabControls can be forced to wrap their headers in a
WrapPanel
, e.g.:materialDesign:TabAssist.HeaderBehavior="Wrapping"
.There is basically now a trigger in the ControlTemplate which swaps out the header of the TabControl.
Note
As of right now the AP can't be changed at runtime. Apparently applying the template when the property changes isn't enough. The TabControl sometimes doesn't show it's content when selecting a Tab after changing the
materialDesign:TabAssist.HeaderBehavior
. I would argue having the need of changing this AP at runtime is rather rare.