(new to WPF) I am looking over the WPF example:
<Window x:Class="Attempt_XAML.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<StackPanel>
<Label HorizontalAlignment="Center">A Button Stack</Label>
<Button HorizontalAlignment="Left">Button 1</Button>
<Button HorizontalAlignment="Right">Button 2</Button>
<Button Background="#FFA29494">Button 3</Button>
<Button>Button 4</Button>
</StackPanel>
</Window>
Remark in MS notes that:
The default value is stretch for both HorizontalAlignment and
VerticalAlignment of content that is contained in a StackPanel.
However, result looks different from what I am expecting. Button and Label are not stretched out vertically, but only horizontally(i.e they don't fill the entire space of Window in both directions) Why ?
Button and Label are not stretched out vertically, but only horizontally(i.e they don't fill the entire space of Window in both directions) Why ?
To understand the reason, you really need at least a basic understanding of Panels. Any Panel such as a StackPanel uses a measure-arrange cycle to decide on a layout for its child elements:
in the "measure" cycle, it assigns a size to each child
in the "arrange" cycle, it positions each child in its view
The key feature of a StackPanel is that it has infinite space -- infinite horizontal space if its orientation is Horizontal, and infinite vertical space if Vertical. In other words, it does not actually pay attention to the size available to it (in the direction of its orientation), but claims an infinite space. So therefore, coming back to your example, even though the VerticalAlignment of the children may be Stretch, they cannot actually be stretched out to an infinite size.
If you need a panel that stretches out its children to fill the available space, then Grid is a good example (by default the Grid will assign an equal share of the total height to each child -- or you can use the star sizing to adjust the proportions). You could also consider creating your own custom Panel, if you need a specialized layout behavior.
Edit
To clarify "infinite space": what I mean is that the StackPanel tells its children that there is infinite space available. What do you do if you are a Button, Label, etc, and there is infinite space available? You probably just take up the minimum space you need, even if your VerticalAlignment is "Stretch", right? That's what happens. Contrast to a Grid, which tells the child controls that they have x (finite) amount of space -- in that case, a Button, Label, etc, will fill up all that space (if their VerticalAlignment is "Stretch").
To illustrate the above, take this custom control as an example:
public class TestControl : ContentControl
{
public string Description { get; set; }
protected override Size MeasureOverride(Size availableSize)
{
System.Diagnostics.Debug.WriteLine("Size available for '" + Description + "': " + availableSize.Height);
return base.MeasureOverride(availableSize);
}
}
This doesn't actually do anything, just reports how much space has been allocated to it. Now, place the test control in a Grid and a StackPanel, and compare:
<Grid Height="50">
<Grid.RowDefinition />
<Grid.RowDefinition />
<local:TestControl Description="in Grid" />
<StackPanel Grid.Row="1" Height="10">
<local:TestControl Description="in StackPanel" />
</StackPanel>
</Grid>
You'll see that the Grid assigns its CustomPanel (the first one above) a height of 25 (half its height). The StackPanel, though, assigns its CustomPanel a height of Infinity.
Although default value is stretch for both HorizontalAlignment and VerticalAlignment of Content that is contained in a StackPanel. But in which direction to stretch is controlled by Orientation Property.
If Orientation is set to Vertical then all the items of the stack with no defined width value are stretched only.
Related
I have a WPF application in which the main window holds a DockPanel with two children. The top child is another DockPanel which holds the menu and is of a fixed size. The lower child is the main work area, which should fill the remaining space and be resizable along with the window. (Hence the DockPanel parent.) Draggable objects get placed in this work area and might appear anywhere inside it.
I'm trying to figure out how to make scroll bars appear if an object is dragged outside the visible area.
The approximate XAML structure currently goes
<Window>
<DockPanel>
<DockPanel with fixed-size content ... >
<ScrollViewer HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Auto">
<Grid ClipToBounds="True" VerticalAlignment="Stretch"
HorizontalAlignment="Stretch"/>
</ScrollViewer>
</DockPanel>
</Window>
So far I've tried a Grid and a Canvas. Both have built-in scroll bars, but they won't appear unless dimensions are specified--but if I apply dimensions, then the panel won't automatically resize to fill the work area.
Then I tried surrounding the panel with a ScrollViewer. The unconstrained panel now successfully auto-resizes to fill the space, but the ScrollViewer has the same problem as the panel--it will only display scroll bars if it's constrained to hard dimensions.
I'm thinking that this would work if I could dynamically constrain the ScrollViewer. So far, I haven't found any reliable way to dynamically apply size values to the ScrollViewer.
Is there a way to create a Binding between the ScrollViewer dimensions and the ActualHeight and ActualWidth of the Grid? Or, is there a way I can define the ActualHeight/ActualWidth of the grid as a DynamicResource that can be applied to the ScrollViewer? Or is there some other panel or method or resource that can be used so that all three criteria (panel fills available space, panel auto-resizes with window, anything dragged outside visible area triggers scroll bars) are met?
Thanks in advance for any help.
The problem was that I did not have a DockPanel.Dock setting on the bottom child of the containing DockPanel. Relying on the DockPanel's LastChildFill wasn't enough to do the job. Once I set DockPanel.Dock = Bottom on the bottom child, the scroll bars started working.
I am currently working with Panels in WPF, and I noticed that as regards the Width and Height properties, there are also two other properties called ActualWidth and ActualHeight.
ActualWidth
Gets the rendered width of this
element. This is a dependency
property. (Inherited from
FrameworkElement.)
Width
Gets or sets the width of the element.
This is a dependency property.
(Inherited from FrameworkElement.)
Reference: MSDN
Can anyone point out the differences between the two and when to use either one ?
Width/Height is the requested or layout size. If you set to Auto, then the value is double.NaN when you access the property in code behind.
ActualWidth/ActualHeight and RenderSize.Width/RenderSize.Height both return the element's rendered size, as RenderSize is of type Size. If you want/need the actual size of the item, then use any of these attributes.
I find ActualWidth most useful when I want to bind the width or height of one element to another.
In this simple example I have two buttons arranged side by side and a comment underneath that is constrained to the width of the StackPanel containing the two buttons.
<StackPanel>
<StackPanel Margin="0,12,0,0" Orientation="Horizontal" Name="buttonPanel" HorizontalAlignment="Left" >
<Button Content="Yes - Arm the missile" FontWeight="Bold" HorizontalAlignment="Left"/>
<Button Content="No - Save the world" HorizontalAlignment="Left" Margin="7,0,0,0"/>
</StackPanel>
<TextBlock Text="Please choose whether you want to arm the missile and kill everybody, or save the world by deactivating the missile."
Width="{Binding Path=ActualWidth,ElementName=buttonPanel}" Margin="0,5,0,0" HorizontalAlignment="Left" TextWrapping="Wrap"/>
</StackPanel>
ActualWidth accounts for padding in the value so anytime you need to know that number you can call Actualwidth instead of width and avoid the calculation.
edit: removed Margin b/c it isn't part of ActualWidth.
ActualWidth is set by the rendering system, and may be different depending on the widths of other elements and overall size constraints. As a result, it can not be changed. Width is a property that can be changed, and should be used to increase or decrease the width of the element.
From MSDN:
This property is a calculated value based on other width inputs, and the layout system. The value is set by the layout system itself, based on an actual rendering pass, and may therefore lag slightly behind the set value of properties such as Width that are the basis of the input change.
There is a very good reason not to use the ActualWidth to bind to (obviously ActualHeight accordingly).
When you set the Width of an element, to the ActualWidth of another one you may break the layout chain.
In the best case your element/control needs to be parsed after the layout process of the parent (the binding source) finished. That means additional time.
If it is at the same hierarchy level as the parent the layout process needs two runs (at least) to calculate a definitive size.
For example I had a control which had it's size property overridden in a style that would set it to the TemplatedParent (don't do):
<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding ActualWidth}"
Height="1" Fill="#000000"/>
When resizing the containing window, the control would prevent the container from becoming smaller and brake the layout. Setting it to the Width will resolve the problem (do):
<Rectangle DockPanel.Dock="Top" Width="{TemplateBinding Width}"
Height="1" Fill="#000000"/>
If you have to use the ActualWidth in general something is wrong with your xaml. Better fix that instead of messing up with the final sizes of the layout run.
It's exactly that, the render width != layout width. One is intended to be used for layout the other one is intended for render. It like with WinForms, there was a Size and a ClientSize property, the differ slightly and you should use the Atual/Client size of rendering and the Width/Height for layout.
You can set the Width property, but not the ActualWidth property.
The Width property is used to determine how the panel is rendered, then the ActualWidth is set to the actual width that was used. This may not be the same value as Width, depending on the size of it's child elements and constrictions from it's parent element.
The ActualWidth is not set immediately when setting the Width property, but will be updated (one or more times) during rendering.
In a UserControl that's inside a ListBox, I've got a TextBlock with proportional width (Width="*") inside a Grid that I want to take the remaining width of the grid, but whenever I resize the ListBox to a size that would clip that TextBlock's content I get a scroll bar. How can I clip the TextBlock width so that I don't get an horizontal scroll bar? Ideally clipping it with ellipsis.
EDIT: Forgot to mention the ListBox.
The listbox is scrolling because it's default behavior is to have HorizontalScrollBarVisibility to Auto.
Try setting this property to disabled:
<ListBox ScrollViewer.HorizontalScrollBarVisibility="Disabled">
As for clipping to an ellipse, this is more complex. You can clip to an ellipsis quite easily using the Clip property:
<TextBlock Text="Some very long thing that I'm putting in here to clip" Background="Blue">
<TextBlock.Clip>
<EllipseGeometry Center="100,8" RadiusX="100" RadiusY="8" />
</TextBlock.Clip>
</TextBlock>
However, to keep the Center, RadiusX and RadiusY in order you'll have to bind it to the height and width of the text box (perhaps using a converter to half these values).
In the image here, each block with a number in it represents a laser. These blocks are laid out on a canvas inside a DockPanel. Also inside the DockPanel docked to the top is the red TextBlock that you can see is hiding behind the laser map canvas. Why is this happening? The TextBlock is docked to the top of the DockPanel and canvas has no dock setting, therefore it should fill the rest of space. Also of note: I had to put the DockPanel inside a ViewBox in order for the whole center screen space to scale properly on window resizes. Then I had to put that ViewBox inside a ScrollViewer to allow scroll bars to appear when needed.
Here is the XAML Code for the center screen (Note: Child of the Window is a DockPanel. Menu is docked to the top, left-hand button panel is docked to the left, right-hand button panel is docked to the right, the status bar is docked to the bottom and everything you see in the center screen is defined by the following XAML code)
<ScrollViewer
Name="centerScreenScrollViewer"
VerticalScrollBarVisibility="Auto"
HorizontalScrollBarVisibility="{Binding IsScrollbarsVisible, Converter={StaticResource BoolToScrollbarVisConverter}, FallbackValue=Hidden}">
<Viewbox>
<DockPanel
LastChildFill="True">
<TextBlock
DockPanel.Dock="Top"
Name="tbkFullVisual"
Style="{StaticResource tbkStyleBlue}"
Foreground="Red"
IsEnabled="{Binding FullVisual}"
HorizontalAlignment="Center"
VerticalAlignment="Top"
FontSize="24">
*** This Print Requires Full Visual Inspection! ***
</TextBlock>
<Canvas x:Name="mapCanvas">
<ContentPresenter Content="{Binding MapCanvas}"/>
</Canvas>
</DockPanel>
</Viewbox>
</ScrollViewer>
Any help in solving this issue will be greatly appreciated.
Regards,
Kyle
This has to do with the way that a ViewBox works, in particular with the Canvas element. The ViewBox is used to resize child elements, as I'm sure you're aware. There are 2 issues with the Canvas element:
The default Height and Width are 0, which means that the TextBlock will get all the space.
The Canvas element lets you draw outside of its own boundaries, so even if your canvas is tiny or not even visible, you would be allowed to render your grid of numbers.
The quickest solution is to set VerticalAlignment on the ViewBox:
<Viewbox VerticalAlignment="Top">
...
</Viewbox>
You could set a Height on the Canvas, but I think this is less ideal because you don't want to change this dynamically with window resize.
I want to be able to align buttons within a stack panel centrally. The number of buttons is dynamic and generated when the control is loaded.
For example, if 1 button is generated then this button should be placed in the center of the control. If 5 buttons are displayed then all 5 should be horizontally aligned next 2 each other but central to the control.
An alternative approach would be to have the control dynamically resize based on its content so it would be wider with more buttons and then horizontally align the user control on the page but I'm not sure how to approach either solution?
Does anybody have any ideas?
This should work. Set the Horizontal Alignment in the stack panel, and make sure when you are dynamically adding your button, you give them each a margin property value to give them some space from each other. horizontal to each other, central to the control.
<StackPanel Orientation="Horizontal" HorizontalAlignment="Center" Margin="20">
<Button Margin="10">one</Button>
<Button Margin="10">two</Button>
<Button Margin="10">three</Button>
<Button Margin="10">four</Button>
<Button Margin="10">five</Button>
</StackPanel>
You can simply set following in XAML
StackPanel.HorizontalAlignment = HorizontalAlignment.Center;
or
HorizontalAlignment="Center" (as GrayFox374 mentioned)
Here is a MSDN sample explaining various alignment operations, having exactly what you need I think -
How to: Horizontally or Vertically Align Content in a StackPanel