This chapter is from the book
This chapter is from the book
This chapter is from the book
Q&A
Q. What unit of measurement is used by XAML?
A. The various length properties use units of pixels, although they are considered logical pixels because they do not always map directly to physical pixels on the screen. Windows automatically scales your app content to either 100%, 140%, or 180% of its natural size based on the size and resolution (and therefore dots-per-inch, or DPI) of the screen. This is why Visual Studio provides different screen size options for the same resolutions in both the simulator and the designer. The latter can be controlled via the Device tool window shown in Figure 3.14.
Figure 3.14 Size matters when it comes to the device’s screen, due to the automatic scaling called out in the “Display” dropdown.
The effect of this scaling can be easily seen with the following XAML placed in a Page:
<StackPanelHorizontalAlignment="Left"><RectangleFill="Red"Height="100"Width="1000"/><TextBlockName="textBlock"FontSize="40"/></StackPanel>with code-behind that sets the TextBlock’s Text to the Page’s current dimensions as reported by the XAML UI Framework:
this.textBlock.Text ="Page size: "+this.ActualWidth"x"+this.ActualHeight;Figure 3.15 shows the result on two different simulator settings. In both cases, the red Rectangle is 1,000 units long as far as your code is concerned. However, it gets scaled larger on the smaller screen (and the Page’s reported bounds are now smaller than the true resolution). Depending on the screen, a user can also bump up the scale from 100% to 140% or 140% to 180% by selecting the “Change the size of apps on the displays that can support it” option in the “Display” section of the PC Settings app.
Figure 3.15 The same page at the same resolution, but under two different simulator screen sizes
Q. What’s the difference between using the CenterX and CenterY properties on transforms such as RotateTransform versus using the RenderTransformOrigin property on UIElement?
A. When a transform is applied to a UIElement, the CenterX and CenterY properties at first appear to be redundant with RenderTransformOrigin. Both mechanisms control the origin of the transform.
However, CenterX and CenterY enable absolute positioning of the origin rather than the relative positioning of RenderTransformOrigin. Their values are specified as logical pixels, so the top-right corner of an element with a Width of 20 would be specified with CenterX set to 20 and CenterY set to 0 rather than the point (1,0). Also, when multiple RenderTransforms are grouped together (described later in this hour), CenterX and CenterY on individual transforms enable more fine-grained control.
That said, RenderTransformOrigin is generally more useful than CenterX and CenterY. For the common case of transforming an element around its middle, the relative (.5,.5) RenderTransformOrigin is easy to specify in XAML, whereas accomplishing the same thing with CenterX and CenterY would require writing some C# code to calculate the absolute offsets.
Note that you can use RenderTransformOrigin on an element simultaneously with using CenterX and CenterY on its transform. In this case, the two X values and two Y values are combined to calculate the final origin point.
)
){kind=link}
Q. How do transforms such as ScaleTransform affect FrameworkElement’s ActualHeight and ActualWidth properties?
A. Applying a transform to FrameworkElement never changes the values of these properties. Therefore, because of transforms, these properties can “lie” about the size of an element on the screen. For example, all the Buttons in Figures 3.9 and 3.10 have the same ActualHeight and ActualWidth.
Such “lies” might surprise you, but they’re usually for the best. The point of transforms is to alter an element’s appearance without the element’s knowledge. Giving elements the illusion that they are being rendered normally enables arbitrary controls to be plugged in and transformed without special handling.
){kind=link}
){kind=link}
Q. How does ScaleTransform affect Margin and Padding?
A. Padding is scaled along with the rest of the content (because Padding is internal to the element), but Margin does not get scaled. As with ActualHeight and ActualWidth, the numeric Padding property value does not change, despite the visual scaling.
Q. Given the impact of transforms, how can I easily get the true position and size of an element?
A. Sometimes you do really need to know an element’s final position and size, taking into account the effects from transforms. For example, several Windows Runtime APIs require the position or bounds of an on-screen element so Windows can display system UI in the right spot.
You can get a window-relative position that accounts for all transforms as follows:
staticPointGetPositionInWindow(FrameworkElementelement) {GeneralTransformtransform = element.TransformToVisual(null);returntransform.TransformPoint(newPoint()/* Represents 0,0 */); }You can get the bounding rectangle as follows:
staticRectGetBoundsInWindow(FrameworkElementelement) {GeneralTransformtransform = element.TransformToVisual(null);returntransform.TransformBounds(newRect(0, 0, element.ActualWidth, element.ActualHeight)); }