does anyone have a functioning virtualising WrapPanel I can use in a WPF application?
I have downloaded and tried the implementation at http://virtualwrappanel.codeplex.com/. However, I get the following exception:
"Layout measurement override of element 'MyNamespace.VirtualizingWrapPanel' should not return PositiveInfinity as its DesiredSize, even if Infinity is passed in as available size."
This is when trying to apply the wrappanel to a ListBox
This is probably a bug that you might be able to fix yourself. Look for the MeasureOverride method. It always seem to return the availableSize wich was passed to the method. As the exception states you must not return availableSize when it contains double.PositiveInfinity. So try this:
if(availableSize.Width == double.PositiveInfinity || availableSize.Height == double.PositiveInfinity)
{
return Size.Empty;
}
// all the measureoverride code comes here
return availableSize;
I haven't looked at the implementation in details. But who knows, you might be able to get a away with this if the panel doesn't save state between MeasureOverride and ArrangeOverride (wich it shouldn't if it is well implemented).
That problem is probably occuring because you have your listbox inside another control, such as a stack panel or scroll viewer, which allows the listbox to grow to whatever size it likes. While the virtual wrap panel shouldn't give an error in this case, it does explain the performance problem.
Even using one of Microsoft's own virtualising panels won't fix the performance issues in this case because the virtualisation is defeated. Since the listbox can grow to whatever size it likes, it does so and draws all the items even if they're not on screen... hence the virtualisation doesn't apply.
If you ensure your listbox isn't inside one of these sorts of containers, you should find the virtualisation starts working performance improves significantly.
Related
I wrote a panel similar to the built-in StackPanel. I works almost fine except for a slight problem:
Changing layout properties on children do not always cause the panel's MeasureOverride and ArrangeOverride to be called. They are always called when a child's Visibility property changes, but not when the Width and Height properties change.
I haven't yet managed to reproduce this behavior in a sample small enough to be appropriate for being included in a question on StackOverflow: But since it works fine in the trivial sample I made, I know I must do something avoidable in my actual panel.
So my question: In which circumstances does an element not invalidate its parents measure when changing size-related properties?
I tag this wpf also (I used Silverlight) to have a broader audience - I suspect this will apply to both xaml implementations equally.
I figured what my mistake was and under which condition the panel's MeasureOverride is no longer called on certain changes for size-related properties.
My panel called Measure on children with the exact size the children should have, rather on the size of the panel.
A panel doesn't get it's MeasureOverride method called when children begin to desire more space than was told to them is available in the last Measure call - which makes sense.
Summary: The parameter for the Measure method you call on a child must denote the space the parent panel allots to all children, not just the one Measure is called on.
You must make sure you call the base methods MeasureOverride.
protected override Size MeasureOverride(Size availableSize)
{
// you must call this
var throwaway = base.MeasureOverride(availableSize);
// your code here
return yourNewSize;
}
It appears that the maximum number of adorners that work without any breakage is 144.
I have a ScrollView with a bunch of objects, and many of them come with adorners. The first 144 adorners are positioned correctly, but the rest are not. Note that it is an exceptional situation when there are so many; usually there are exactly zero adorners. Nevertheless, I'd like this to work properly even on that exceptional occasion.
Leaving aside how this arbitrary (and very low) limit makes me feel, are there any practical work-arounds for this bug?
At this time there is no known way of doing this.
Which is just as well, because I found the performance to be poor; simply subclassing my Image control that was supposed to display the adorner, and drawing the overlay in the OnRender, worked much better (and unlike WinForms, the visual can extend beyond the logical boundary of the control).
Here is the scenario under which I managed to implement a workout for this problem:
I have a number of textboxes that are linked to an Excel document.
The textboxes take a numerical value. They are set to invalidate on data errors in the xaml code. A data error occurs if the number is < 1, or null.
I placed an AdornerDecorator around the textbox (so that the red invalidation border appears correctly over the textbox).
In Excel, you can alter all the textboxes at the same time - but, as the OP found, if you manage to invalidate over 144 text boxes at once, the adorner decorator starts playing up, offsetting the position of the borders (the very thing it was designed to fix in the first place).
I tried a number of different solutions including invalidating the layout, however none of these worked for the situation I was facing.
Using Snoop, I found that if I refresh the textbox manually, the adorner then placed itself correctly. So, I decided to call an update to the layout from each individual textbox that needed the adorner. I did this by listening for OnValueUpdated on the textboxes. If the new value it was updating to happened to be an invalid value, I force an "UpdateLayout()" for the textbox (I only wanted to do this for invalid values as forcing an update impacts performance, and I don't want to do that every time the value changes).
In this way, regardless of the number of cells I wanted to change at once, the adorner decorator was always displayed in the correct position (except for the very last textbox to be evaluated which, despite my best efforts, is always ever so slightly misaligned).
This might be way late to the party here, but this seemed to solve the problem for me. I kept a list of the adorners that I had added to the adorner layer (called m_adorners), and in the root control where my adorners were contained, I attach to the LayoutUpdated event. Here's event handler:
private void OnLayoutUpdated(object sender, EventArgs e)
{
if (m_adorners.Any(a => !a.IsArrangeValid &&
a.Parent != null))
{
AdornerLayer adornerLayer = AdornerLayer.GetAdornerLayer(this);
adornerLayer.InvalidateArrange();
}
}
I've written a custom panel which displays its children docked either vertically or horizontally, separated by moving splitters in between. Since the Grid panel offers much of this functionality out-of-the-box, I just inherited from it.
To create the layout, upon Loaded is fired I do the following:
1) Read how many children it has and create the appropiate number of rows/colums.
2) Position every existing children in the corresponding row/colum.
3) Create, position and add a GridSplitter for every child.
This approach looks and works fine, but it opens the door to a lot of problems:
Since it's added a GridSplitter for each child, there are twice the number of expected children. If someone added 3 elements to it, Children.Count would return 6.
User could insert/remove things at the wrong place.
It just throws an exception when this Grid is used as the ItemsPanel for an ItemsControl, since in this case WPF (not Silverlight) does not allow direct children manipulation.
These 3 cases are the ones I've already tested, but I'm pretty sure a lot more would arise depending on what the user does with it.
As it turns out, this class must be regarded as 'implementation details', so the real question is, what control should I put in front of the user?
It sounds like it should be a Panel, but I can't control the Children property since it's not virtual, and there's also the ItemsControl which I think could be a good candidate, but I really don't know.
I'd much appreciate any kind of advice or some directions to do this the right way.
Thanks in advance.
You see using just grid you leave yourself with an imperative way of adding items only. As in
myCustomGrid1.AddMyItem(***), Grids simply don't have ItemsSource property. ItemsControls do - so if you need support for declarative items sources i.e. myControl.ItemsSource = {Binding ...} you're going to derive your control from ItemsControl. This is not a two liner - making your ItemsPanel Children writable is a big challange - there's no simple way of doing that.
This is all about a small thing overlooked during the Grid's design - splitters shouldn't have been added to Children collection, as Children are visulaizations of your BOs while spliiters are just formatting elements.
Here's what I would do.
Forget about ItemsSource & items altogether - it's aint worht the hassle. The only way to add/remove items to your control will be AddResiazableItem/RemoveResizbleItem. Calls will add items and splitter (for the middle items), extend the number of rows/cols of your grid depeneding on its orientation, set Grid.Row/Grid.Column attached properties for your visual children. You can keep your actual objects internally to support Orientation change.
If at any stage you'll want to bind your control to IEnumerable source - just create an attached behavior, which will iterate through the items and call AddResiazableItem within a loop.
Cheers.
P.S. To moderators - the editor seems to get broken, lads. I cant see the second item.
P.S.S. Got it fixed after a few tries.
I need to develope a WPF custom control to show the layout and connectivity of nodes in a wireless mesh network. The user needs to be able to drag the nodes around. The canvas should grown and Scrollbars should appear as required if elements get draged off the available space. The ability to zoom in/out might be required.
My first take on this is to use a ListBox derived CustomControl with a Canvas based ItemsPanelTemplate. To get things moving Im using Josh Smiths DragCanvas that allows UIElements children of the canvas to be dragged around. My "node" class is not currently UIElement derived (the DragCanvas is currently working with the ListBoxItems that wrap my nodes).
1. Is this a bacially sensible approach or should I be abonding the ListBox idea and going something lower level?
2. I have to overlay the inter node link lines - not currently sure how to go about this (as a UIElement class that is part of the ControlTemplate?)
3. A few people seem to be having a headache with scrolbars in Canvases - is this going to be an issue?
Any general or specific advice most appreciated.
Wow, not bad as a control!
I am doing something similar, but it is not so simple.
1) IMHO, the DragCanvas is a basic way to host+drag elements. Since you will have to host labels (nodes), arcs and labels again (arcs' weight), I think the DragCanvas would be harder than write a custom control by yourself.
Not everything comes easy with templating: sometime is much better the "old" approach winforms-like, or even a hybrid way.
2) As stated, I'd create a Canvas-derived panel, which will host several UIElements (labels, arcs, etc). All of them should be governed by a model+viewmodel. That's a bit harder at the beginning, but it will give you a lot of satisfaction and flexibility in the future.
3) I don't think the Canvas will give you any headache! A Canvas full of elements has always a size of zero. That leads "headaches" for those trying to add a scrollviewer.
Instead, the Canvas-derived class (above) should override the MeasureOverride method, so that its size will fit any of the hosted objects. However, it is a bit annoying the fact you cannot use negative coordinates (it will cause scrolling problems).
It's hard to describe in few lines all the work behind a similar "editor". The task isn't easy, and the problems are many.
Hope it helps, anyway.
Cheers
I was looking at FrameworkElement.MesureOverride on MSDN, trying to understand the mechanism behind the layout engine. I stumbled upon this interesting note :
During this process, child elements might return a larger DesiredSize size than the initial availableSize to indicate that the child element wants more space.
Ok. I had reflector near so I looked into MesureCore, which call MesureOverride and I noticed that, from what I could understand, the return value of MesureOverride is always capped between 0 and the availableSize. So what's up with that?
A child element can ask for more space. Whether that is honored by the parent element is up to the parent element.
MeasureCore only calls MeasureOverride on this. You're only getting a very small part of the story. The Layout System starts with calling Measure on the topmost Panel in the tree of elements, which calls MeasureCore on this. However, MeasureCore in FrameworkElement calls MeasureOverride in a couple of places.
Where are you seeing it cap between 0 and availableSize?
Edit: Re: "well, the last line of MeasureCore..."
Like I said, you're looking at a small part of all that goes on.
All controls have 1 very common way to request more space than they actually need: Margin. You'd have to write a custom control to request even more space than that.
The constraints you see in MeasureCore, from what I can tell, have to do with the MinWidth/MinHeight and MaxWidth/MaxHeight limits, if they are set.
So yeah, a control -- like the documentation says -- can request more space than is needed. None of the default controls seem to do this aside from their Margins, and containers such as panels don't have to respect it. Most circumstances don't take advantage of what you read in the documentation because in most circumstances, it wouldn't make sense from either the perspective of the parent of the child.
If you created a UserControl, got rid of the Width and Height values in the XAML and override MeasureOverride to return an arbitrary Size, then place an instance of it in a Canvas, you would see it display at the Size you returned.
This feature of the layout system may be of use if you are creating custom panels and custom controls or user controls, but otherwise probably not. But it is there. The documentation is correct.
If you return a Size > availableSize from your own MeasureOverride method, FrameworkElement.MeasureCore (calling your method) will remember it, but DesiredSize will be set = availableSize. This guarantees that child control will be suitable for (for instance) Grid cell with explicitly specified Width/Height. BUT because FrameworkElement.MeasureCore remembers your "unclipped" DesiredSize, in ArrangeOverride you should receive a parameter = your original DesiredSize. At result of it your control "virtually" arranges children according to its original DesiredSize, but FrameworkElement implementation will clip your control for such parent Grid cell. Concrete clipping manner will depend of actual values of properties like Horizontal/VerticalAlignment (properties of your control).