On iOS and Android, setting
RelativePanel.AlignHorizontalCenterWithPanel or RelativePanel.AlignVerticalCenterWithPanel does not work.
The element with RelativePanel.AlignHorizontalCenterWithPanel='true' and RelativePanel.AlignVerticalCenterWithPanel='true' is centered horizontally and vertically, like on the UWP head.
<Page
x:Class="App1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:App1"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">
<RelativePanel Background="DarkOrange">
<TextBlock RelativePanel.AlignHorizontalCenterWithPanel="True" RelativePanel.AlignVerticalCenterWithPanel="True">This text should be centered horizontally and vertically.</TextBlock>
</RelativePanel>
</Page>
Nuget Package:
Uno.UI: 1.46.0-dev.2121
Affected platform(s):
Visual Studio
I will look at this
Also applies to WASM
Also applies to WASM
Gotcha, reflected that on the issue sheet.
@jeromelaban Ok, I underestimated this :-D . After spending the last few hours stepping through the RelativePanel.Layout.SiblingGraph code, I will for now leave this unassigned, as I can fix it with a workaround, but can't say for sure if that would not break the layout algorithm for other cases (e.g. with more siblings). What I can confirm is that this does not happen if Height and Width are set explicitly. Instead, it happens for controls like TextBlock which return their measured size in MeasureOverride. In such case, ComputeChildLeftBound and ComputeChildTopBound returns the full size of the RelativePanel and the ComputeChildArea then does not know the element should be actually centered and puts it to the left/top position instead.
You can reproduce it with the following unit tests:
private class MeasuredControl : Control
{
private readonly Size _measureSize;
public MeasuredControl(Size measureSize)
{
_measureSize = measureSize;
}
protected override Size MeasureOverride(Size availableSize) => _measureSize;
}
[TestMethod]
public void When_Child_Aligns_Horizontal_Center_With_Panel()
{
var SUT = new RelativePanel()
{
Name = "test",
Width = 1000,
Height = 1000
};
var border = new MeasuredControl(new Size(100, 100));
border.SetValue(RelativePanel.AlignHorizontalCenterWithPanelProperty, true);
SUT.Children.Add(border);
SUT.Measure(new Size(1000, 1000));
SUT.Arrange(new Rect(0, 0, 1000, 1000));
Assert.AreEqual(new Rect(450, 0, 100, 100), border.Arranged);
}
[TestMethod]
public void When_Child_Aligns_Vertical_Center_With_Panel()
{
var SUT = new RelativePanel()
{
Name = "test",
Width = 1000,
Height = 1000
};
var border = new MeasuredControl(new Size(100,100));
border.SetValue(RelativePanel.AlignVerticalCenterWithPanelProperty, true);
SUT.Children.Add(border);
SUT.Measure(new Size(1000, 1000));
SUT.Arrange(new Rect(0, 0, 1000, 1000));
Assert.AreEqual(new Rect(0, 450, 100, 100), border.Arranged);
}
The workaround I found worked for this specific case was to explicitly set the Center property in ComputeChildTopBound and ComputeChildLeftBound if the GetAlignVerticalCenterWithPanel and GetAlignHorizontalCenterWithPanel is true. However, I am pretty sure that would break other things...
I would love to spend more time with it, but I can't procrastinate from writing the master thesis more than I already did 馃槀 .
Thanks for the effort @MartinZikmund
Thanks @MartinZikmund! This is indeed special cases like those that make this control a bit special.
Our stance for this control is to wait and see what Microsoft is going to be providing with the WinUI 3.0 open sourcing and adjust the behavior accordingly.
Just wanna say that the RelativePanel is my favorite layout control and one of the things that really, IMO, sets UWP apart from most other Markup languages. While I totally agree that it needs to be done the right way (and y'all would know better than I what that is), I'm going to go a little nuts waiting for it. This will make porting existing UWP apps significantly more difficult until it's fixed.
Most helpful comment
Thanks @MartinZikmund! This is indeed special cases like those that make this control a bit special.
Our stance for this control is to wait and see what Microsoft is going to be providing with the WinUI 3.0 open sourcing and adjust the behavior accordingly.