fix(wpf): ship a default theme in ReactiveUI.WPF.Reactive so ViewModelViewHost renders#4412
Draft
glennawatson wants to merge 1 commit into
Draft
fix(wpf): ship a default theme in ReactiveUI.WPF.Reactive so ViewModelViewHost renders#4412glennawatson wants to merge 1 commit into
glennawatson wants to merge 1 commit into
Conversation
…lViewHost renders - Extract the TransitioningContentControl control template into a single shared theme dictionary (ReactiveUI.Wpf.Shared/Themes) that targets the built-in ContentControl, so it carries no assembly-specific type and one copy packs into both WPF assemblies. - Add a per-assembly Themes/Generic.xaml to each WPF leaf that merges the shared template and binds it to that assembly's TransitioningContentControl via a bare clr-namespace; the .Reactive assembly now ships its own themes/generic.xaml theme dictionary. - Previously ReactiveUI.WPF.Reactive shipped no themes/generic.xaml, so the control's default template was never found and ViewModelViewHost stayed blank. - Add a theme-template resolution test that runs against both WPF assemblies. Closes #4394
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What kind of change does this PR introduce?
Bug fix.
What is the new behavior?
ViewModelViewHost(and its baseTransitioningContentControl) now resolve their default control template when used from theReactiveUI.WPF.Reactivepackage, so the resolved view is inserted into the visual tree and the content is displayed.The single ~40 KB
TransitioningContentControltemplate is authored once, in a shared theme dictionary (ReactiveUI.Wpf.Shared/Themes/TransitioningContentControlTemplate.xaml) that targets the built-inContentControland therefore names no assembly-specific type. Each WPF assembly ships a smallThemes/Generic.xamlthat merges the shared template and binds it to that assembly's ownTransitioningContentControlthrough a bareclr-namespace. As a result bothReactiveUI.WPFandReactiveUI.WPF.Reactivepack their ownthemes/generic.xamltheme dictionary from a single source template.What is the current behavior?
TransitioningContentControlsetsDefaultStyleKey = typeof(TransitioningContentControl)and the assembly declaresThemeInfo(SourceAssembly), so WPF looks for the default template in each assembly's ownthemes/generic.xaml. The leanReactiveUI.WPFassembly packed one and worked, butReactiveUI.WPF.Reactiveshipped no XAML at all - so itsthemes/generic.xamlwas missing, the default template was never found, andViewModelViewHostrendered nothing (blank window). Manually merging the lean package's theme dictionary worked around it.Closes #4394
What might this PR break?
None expected. No public API changes. The lean
ReactiveUI.WPFtheme is sourced from the same shared template and continues to resolve as before.Checklist
mainbranchAdditional information
Root cause note: a XAML
xmlnsmapped tohttp://reactiveui.netcannot resolve a control type defined in the same assembly being compiled - the markup compiler resolves URI namespaces against referenced assemblies only, while a bareclr-namespaceis what defers local-type resolution to the second markup pass. That is why one physicalGeneric.xamlusing the URI namespace fails to compile in the defining assembly, and why the template body (shared, type-free) is split from the tiny per-assembly type binding.Verified by building both WPF assemblies (clean, correct
themes/generic.baml+themes/transitioningcontentcontroltemplate.bamlresource paths) and running the theme-template resolution tests plus the existingViewModelViewHost/TransitioningContentControltests against both the lean and.Reactiveassemblies (via the net8.0-windows TFM under Wine). CI on windows-latest is authoritative.