fix(FrameworkElement): [macOS] Ensure we set parent to a DependencyObject #5183
Conversation
This file contains 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
|
|
kazo0
commented
Feb 8, 2021
| _superViewRef = new WeakReference<NSView>(superView); | ||
| SyncBinder(superView, newWindow); | ||
| ((IDependencyObjectStoreProvider)this).Store.Parent = superView; | ||
| _superViewRef = new WeakReference<NSView>(parent); |
There was a problem hiding this comment.
Still not sure about what should be set here, the "real" Superview or the ancestor that we may have found that is a DependencyObject?
There was a problem hiding this comment.
I'm not sure either - it only seems to be checked here, and TBH I'm not clear on what the intent of the check is.
Any thoughts @jeromelaban ?
There was a problem hiding this comment.
An actual dependency object should be set, otherwise the DependencyObjectStore may not be able to traverse to the root.
There was a problem hiding this comment.
But even for the _superViewRef? We shouldn't set that to the actual Superview regardless of it being a DependencyObject?
There was a problem hiding this comment.
@kazo0 I would leave it as you have it, setting it to parent (the actual dependency object), but I'm still not sure what the check is even for.
|
The build 24574 found UI Test snapshots differences: Details
|
jeromelaban
reviewed
Feb 8, 2021
| _superViewRef = new WeakReference<NSView>(superView); | ||
| SyncBinder(superView, newWindow); | ||
| ((IDependencyObjectStoreProvider)this).Store.Parent = superView; | ||
| _superViewRef = new WeakReference<NSView>(parent); |
There was a problem hiding this comment.
An actual dependency object should be set, otherwise the DependencyObjectStore may not be able to traverse to the root.
| @@ -103,6 +105,26 @@ namespace <#= mixin.NamespaceName #> | |||
| this.Log().Error($"Failed to process MoveToWindow for {GetType()}", e); | |||
| } | |||
| } | |||
|
|
|||
| private static DependencyObject GetDependencyObjectAncestor(NSView firstGuess) | |||
There was a problem hiding this comment.
There's FindFirstParent<DependencyObject>() that does this.
kazo0
force-pushed
the
dev/sb/scrollview-bind
branch
from
7190e00
to
81bb0b3
Compare
|
The build 24592 found UI Test snapshots differences: Details
|
|
The build 24592 found UI Test snapshots differences: Details
|
davidjohnoliver
approved these changes
Feb 9, 2021
| _superViewRef = new WeakReference<NSView>(superView); | ||
| SyncBinder(superView, newWindow); | ||
| ((IDependencyObjectStoreProvider)this).Store.Parent = superView; | ||
| _superViewRef = new WeakReference<NSView>(parent); |
There was a problem hiding this comment.
@kazo0 I would leave it as you have it, setting it to parent (the actual dependency object), but I'm still not sure what the check is even for.
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
closes unoplatform/Uno.Gallery#129
closes unoplatform/Uno.Gallery#130
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Bindings are not propagated properly when using a ScrollViewer since the FrameworkElement Implementation of
ViewDidMoveToWindowtries to set theWhat is the new behavior?
Bindings are properly propagated
PR Checklist
Please check if your PR fulfills the following requirements:
Screenshots Compare Test Runresults.