Open michael-hawker opened 3 years ago
@RealTommyKlein can you weigh in?
Hmmm, was just looking at a WinUI 3 (internal) Bug around Binding and Event Loading, though not sure if it's supposed to effect x:Bind as well, but also for UWP. Wonder if this is one of those UWP type cases where Binding/Loading is non-deterministic...?
However, it's weird as it either always seems to succeed or always fail, but just depends on the composition of the Visual Tree...
FYI @evelynwu-msft too.
This feels like a completely different issue from 32092234.
This is from the framework optimizing incorrectly, and not creating the CommonShadow
object when it's actually needed. Xaml defers creating ResourceDictionary
entries until they're actually referenced/needed (e.g. from a StaticResource
reference or someone accessing ResourceDictionary
entries in code-behind).
In the examples, Step 3 works because the Image
has a StaticResource
reference to CommonShadow
object, so the framework will create it. Step 4 doesn't work when the Button
is commented because nothing in the code actually references CommonShadow
. However, when the Button
is uncommented, the implicit style for Button
defined in the dictionary needs to be applied (and therefore instantiated itself) - when the implicit style is made, its ui:Effects.Shadow
setter references CommonShadow
, causing CommonShadow
to be created and making everything work again.
One workaround is to use x:Name
for CommonShadow
instead of x:Key
, which will force the framework to instantiate it. However, the framework should really be force instantiating any objects with x:ConnectionId
on them (which are secretly added by the Xaml compiler before the .xaml
is fed to the parser - in this case CommonShadow
would have one). x:ConnectionId
indicates some Xaml compiler generated code-behind needs them (e.g. x:Bind
).
We already detect if x:Name
is present on a resource and force it to be undeferred so it should be straightforward to extend the same logic to x:ConnectionId
.
Describe the bug I somehow stumbled upon a
NullReferenceException
in the generated x:Bind code when the element containing the binding wasnull
. However, it only occurs in a certain scenario when the resource is not directly referenced from outside the ResourceDictionary. i.e. if the resource is only referenced from within the resource dictionary the binding to it fails; however, when the resource is used within the main visuals below it, the binding works.However, it seems to only reproduce with specific sets of XAML trees as well. There's definitely some weird timing/initialization issue going on here.
Steps to reproduce the bug Steps to reproduce the behavior:
Microsoft.Toolkit.Uwp.UI
package version 7.1-rc1 or later.If you uncomment out the button, then the binding is successful.
This now fails even though it appears similar to step 4 scenario when the button is uncommented. If you add the
ui:Effects.Shadow="{StaticResource CommonShadow}"
property to the blank lines in the first Image and/or the last Rectangle then the sample works fine again! 🤷♂️ScrollViewer
...?Expected behavior Binding doesn't throw null reference exception, still should bind...
Screenshots
Version Info
NuGet package version: None, WUX OS XAML UWP
Additional context Discovered in final testing of our Attached Shadow Toolkit PR here: https://github.com/CommunityToolkit/WindowsCommunityToolkit/pull/4179