I wish to use XAML to create a calculator like interface.It should contain buttons upto 1000.
I've read about virtualizing stack panel but i'm not sure how to use it with a listbox and do data binding with that list for the content. Can you please help me with virtualizing stack panel concept
ListBox includes a Virtualizing StackPanel by default, so you dont need to worry about it, or how to implement it. FYI, the Virtualizing StackPanel only creates UI elements (in your case the Buttons), when they come into View. An aditional improvment is to switch on container Recycling:
<ListBox VirtualizingStackPanel.IsVirtualizing="true" VirtualizingStackPanel.VirtualizationMode="Recycling" />
Related
The documentation for the Grid class states:
Starting in Windows 10, Grid defines new border properties that let you draw a border around the Grid without using an additional Border element. The new properties are Grid.BorderBrush, Grid.BorderThickness, Grid.CornerRadius, and Grid.Padding.
Does this make the Border class redundant? Why would I ever want to use a Border if I can do the same thing with a Grid and lay out children in a grid fashion if I so choose?
EDIT
I generally agree with Bart's answer, but there's a few things I would like to talk about.
Firstly, other layout controls (like StackPanel) do indeed have Border-like properties such as BorderBrush, BorderThickness and CornerRadius, so Grid isn't the only layout control which gets these new perks. But they are not attached properties provided by the Border class (or have anything to do with the Border class at all).
Secondly, I, too, thought that it would be a overkill to use complex layout control like Grid if I only wanted to add a border to a simple control like an image. But surely these layout controls would be optimized such that any impact to layout rendering speed would be negligible if they only contained a single child without any special layout constraints. So using a Grid instead of a Border shouldn't affect performance when it only has a single child.
Lastly, I decided to find out just how Grid achieves the border appearance. I created a simple Page containing a Grid with a border and a single Rectangle child, like this:
<Grid Background="Red" BorderBrush="Blue" BorderThickness="10">
<Rectangle Width="50" Height="50" HorizontalAlignment="Left" VerticalAlignment="Top" Fill="Yellow"/>
</Grid>
with the following rendering:
Upon inspecting the live visual tree, the Grid class does not add any additional elements to the visual tree to make the border appearance:
I suspect whatever mechanism it uses to create the border appearance would be the same as what the Border control does (maybe it creates an additional Visual in the composition layer).
So I'm not really convinced that the "simpler" Border control would be better to use because it looks like the Grid control is already quite performant. I can't see any evidence for the Grid control adding any extra overhead to the visual tree (when compared to what a Border would do to achieve the same effect).
So far the only reason I can think of why I should use Border instead of Grid is to express meaning. It's obvious what the Border control does, adds a border around a single element. Grid is a layout control used to lay out child elements within a grid (which, as it so happens, has the ability to add a border around its children too as an added bonus).
Your first question designing your UI should be do I need a Grid or another layout control (StackPanel, RelativePanel, Canvas, ...) based on the specific behavior of each control (see MSDN). Note that next to Grid, also StackPanel and RelativePanel have Border attached properties. These attached properties are bonus for you to not add another 'redundant' control in your XAML tree to wrap your layout control in.
Why is the Border control NOT obsolete? Let's say you want a border around an image (which is inside any of the above mentioned layout controls together with other items, so you can't reuse the layout control's border). Now you have 2 options:
wrap the image in a Border control.
wrap the image in a Grid (or other layout control) and abuse the attached properties.
My wording should be clear which one is best: pick the Border control. A rule of thumb is: keep your visual tree as small as possible. Opt for the simplest control doing the task. Placing an image in a Grid just for having the border around it adds to much extra overhead in your visual tree.
I have a requirement to create a button in a Windows 8.1 app which has an icon and a text label. The icon will be a symbol from Segoe UI Symbols and the text label will be Segoe UI Semibold at a smaller text size.
I want to be able to reuse the button in different places within the app, using different icons and text labels.
How show I go about this? I could create a button and then edit the ContentPresenter to have a horizontally oriented stack panel with two TextBlocks, but then how could I reuse this? And how could I change the text in the two different text blocks?
Should I create a separate custom control with separate dependency properties for each of the textblock strings? I'm interested in hearing what you would do.
thanks
Create a simple Style. To make it easy, I would base it off the standardized AppBarButton style. You can format it to whatever size you want (I have done something similar to make a larger button or one with text on the side).
Have the main icon simply be a ContentPresenter which binds to the Content using a TemplateBinding. Make sure to set the FontFamily to Segoe UI Symbol. Have the text label pull from AutomationProperties.Name, similar to how the AppBarButton style does.
Then, whenever you want to use this just do:
<Button Style="{StaticResource MyCustomButtonStyle}"
Content="" // Where "000" is replaced by the number of the icon you wish to use.
AutomationProperties.Name="Text Label"/>
This should be extensible and easily reproducible to whatever location you need. When copying over the AppBarButton style, I suggest removing the artificial size limits (specifically the width of the main content Grid). I do suggest either giving the Text Label a fixed size or having it pull its size from the specified parent Width, so that it will Wrap correctly.
Hope this helps and happy coding!
Are you desiring to create something like for an AppBar? Take a look at AppBarButton and the style/types it supports. In Windows 8.1 we added some things around SymbolIcon specifically. Since you basically want two pieces of 'content' for your style you'll have to re-purpose one property (unless you create a custom control which doesn't sound needed for this scenario). Using AutiomationProperties.Name for the visible label is a good idea because it will also help with accessibility by default for those users.
Investigate the style for AppBarButton to get you started.
I'd like to get the effect visible on the picture:
I don't think it is. A GridView already has a ScrollViewer in itself, so multiple of them does not make sense. I would try to use a single GridView with GroupStyleSelector/ItemContainerStyleSelector/ItemTemplateSelector implementations and DataTemplates to define each item. A less dynamic version might just be a ScrollViewer with Style set to HorizontalScrollViewerStyle, a horizontal StackPanel and a few VariableSizedWrapGrids - if you bind the GridView to some groups or other panels to define the content.
This looks like a good sample based on the description (though the images seem to be missing for me).
I've got a WrapPanel which will contain several different custom UserControls. Depending on the scenario, I may need to filter down which UserControls are visible. My goal is that I can switch which controls are visible on the fly by showing/hiding the controls that need to be filtered - thus shifting the controls that are left showing, to the top-left of the panel.
Right now I am simply setting the Visibility property of the control to Visibility.Collapsed when I don't want them to appear. I thought that because I was using a WrapPanel, the rest of the controls would shift to the top-left of the panel.
Instead, after hiding some of the UserControls, the controls that are still visible stay exactly where they were before, and I am left with gaps between the controls that are still showing. I've opened my app in Silverlight Spy, and it shows that the UserControls are still actually there (which makes sense) but are simply invisible.
So my question is:
Is there a way that I can show/hide UserControls within a WrapPanel which allows the still-visible UserControls to slide to their new positions (all shifting towards the top left - similar to a StackPanel)?
I've debated removing the UserControls completely from the WrapPanel (I think this would work) and storing them in memory until they are needed. Then if I wanted to show/hide other controls, I would get them from my in-memory object. It seems like there should be a better way to do this though.
If anyone has any suggestions or advice, it would be greatly appreciated. Thanks!
-Lloyd
UPDATE:
XAML: (very simple)
<toolkit:WrapPanel x:Name="MyLayout" Height="300" HorizontalAlignment="Left" VerticalAlignment="Top" Width="400" />
Code-Behind: The UserControls are getting added dynamically:
MyLayout.Children.Add(oUserControl)
And they are getting set to collapsed dynamically as well:
oUserControl.Visibility = Visibility.Collapsed
I think I've found the problem. We added the WrapPanel to a ScrollViewer recently, and when I took the ScrollViewer out I was able to achieve the functionality I wanted.
I'm not sure why the ScrollViewer would have that effect though?
Also, I've found that I can leave the ScrollViewer in place and simply call .Measure() on the WrapPanel to update the layout.
Neither option makes 100% sense to me, but they do both seem to work.
As I understand it, a Panel isn't meant to have any visible "chrome." The StackPanel, Grid and Canvas don't have any visible elements (with the exception of the gridlines, which they say are only for debugging layout.)
In my example, I am going to create a Custom Panel that uses Attached Properties to lay out its children controls. However, I want my Custom Panel to present a visible "grid" of sorts in the background. The look of the grid (sizing and positioning) will depend on the size and position of the child elements.
What are some of the ways to achieve this? Being very new to Silverlight and XAML in general, my first guess was to create a Custom Control which includes my custom panel for layout.
I think I'll be able to figure out the specific code, but I need to be pointed in the right direction in terms of what building blocks are appropriate for this scenario.
You are correct that custom Panels cannot show any extra chrome; they can only display their Children (Grid being an exception).
To do what you want to do, you could create a custom Panel which just adds extra Children to display the chrome. This would not be a good design though (since users of the Panel would see these extra items in the Children collection).
The best idea is to do what you said: create a custom Control that exposes a Children property. This control could internally use a private custom Panel to lay out these elements (e.g. TabControl uses a special TabPanel for laying out the tabs). In the Controls default template, you might want to use TemplateBinding on the Panels' Children property to your Control's Children property.
Panel can add Adorners to its children, read this article about adorners: http://msdn.microsoft.com/en-us/library/ms743737.aspx