Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Two (Closely Related) RelativeSource Binding Issues #8450

Closed
legistek opened this issue Nov 9, 2019 · 0 comments
Closed

[Bug] Two (Closely Related) RelativeSource Binding Issues #8450

legistek opened this issue Nov 9, 2019 · 0 comments

Comments

@legistek
Copy link
Contributor

legistek commented Nov 9, 2019

Description

(1) RelativeSource bindings using the FindAncestorBindingContext mode do not get re-applied when the BindingContext of any of the ancestors changes without re-parenting. This may or may not be the problem @IoTFier was having but investigating his issue led to my discovery of this problem.

(2) I misinterpreted the WPF documentation for AncestorLevel when reproducing it for XF. The correct behavior is that an AncestorLevel of n skips n-1 instances of the AncestorType in the tree. The current behavior is that it skips n-1 levels (regardless of type) in the visual tree.

Steps to Reproduce

For (1), simply create a binding using the FindAncestorBindingContext RelativeSource mode and change the BindingContext of the source during the lifecycle of the app. The bound target will never update.

For (2):

<StackLayout StyleId="stack1">
     <StackLayout StyleId="stack2">
          <Grid>
               <Label Text="{Binding StyleId, Source={RelativeSource AncestorType={x:Type StackLayout}, AncestorLevel=2}}"/>
          </Grid>
     </StackLayout>
</StackLayout>

Expected:
Label text = stack1

Actual:
Label text = stack2

Resolution

I've coded a fix and more robust unit tests here. If there's no objection will I submit a PR imminently. cc: @StephaneDelcroix

@legistek legistek added s/unverified New report that has yet to be verified t/bug 🐛 labels Nov 9, 2019
@pauldipietro pauldipietro added this to New in Triage Nov 9, 2019
@StephaneDelcroix StephaneDelcroix removed the s/unverified New report that has yet to be verified label Nov 19, 2019
@StephaneDelcroix StephaneDelcroix moved this from New to Ready For Work in Triage Nov 19, 2019
@samhouts samhouts moved this from Ready For Work to Needs Estimate in Triage Nov 19, 2019
@samhouts samhouts added this to In Progress in v4.4.0 Nov 22, 2019
@samhouts samhouts moved this from In Progress to Done in v4.4.0 Nov 22, 2019
@samhouts samhouts removed this from Needs Estimate in Triage Nov 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
v4.4.0
  
Done
Development

No branches or pull requests

3 participants