-
Notifications
You must be signed in to change notification settings - Fork 80
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
ContentSizer sets Width to 0 if layout hasn't completed #85
Comments
Was able to write a test which I think demonstrates this issue: Ah, and I found the key comment too:
So that's why we need to set the Width somewhere... I think I'll do this check in the |
I wonder if the original code re-used the Basically, this should be better behavior, as now the Opening a PR... :) |
ContentSizer was overwriting Width to Zero causing initial layout problems of a component, instead this code is removed as it is not needed to maintain the same behavior. Added a test to validate the old behavior was incorrect and the new desired behavior should work.
ContentSizer was overwriting Width to Zero causing initial layout problems of a component, instead this code is removed as it is not needed to maintain the same behavior. Added a test to validate the old behavior was incorrect and the new desired behavior should work.
ContentSizer was overwriting Width to Zero causing initial layout problems of a component, instead this code is removed as it is not needed to maintain the same behavior. Added a test to validate the old behavior was incorrect and the new desired behavior should work.
Related to #26
Discovered as part of work on DataTable experiment in labs in this branch/commit here: CommunityToolkit/Labs-Windows@47f46df#diff-b874aea5366fbeacbd08eec0606a72bf3b458be31ff250be121b9c9f5ec7b49d
Basically, when the target control was being set in this scenario, the layout hadn't occurred yet on the, so the
DesiredSize.Width
is still '0'; which means theWidth
of the component is set to0
and is never updated or changed making it invisible.Instead, if the
DesiredSize
is not set yet, then we shouldn't manipulate theWidth
of the control, as the patch above did.We set the
Width
property is that's modified by the sizing behavior:Windows/components/Sizers/src/ContentSizer/ContentSizer.Events.cs
Lines 36 to 50 in 744e6ab
However, when we start to drag we measure the
ActualWidth
(or Height) here:Windows/components/Sizers/src/ContentSizer/ContentSizer.Events.cs
Lines 24 to 33 in 744e6ab
So, in theory we may just be able to remove this initial code all together?
The text was updated successfully, but these errors were encountered: