bug

Problems when re-assigning a PathGeometry in Silverlight


Warning: count(): Parameter must be an array or an object that implements Countable in /nfs/c03/h02/mnt/50561/domains/gergelyorosz.com/html/wp-content/plugins/wp-syntax/wp-syntax.php on line 76

I wasn’t planning in submitting (yet) another workaround for a Silverlight bug, but I stumbled across (yet) another annoying issue that causes no problems in WPF, but results in a exception being thrown in Silverlight. It definitely seems like another Silverlight bug still present in Silverlight 4.

The problem

I was building Paths by re-using a pre-built collection of PathGeometries. However when re-assigning a PathGeometry to another Path like this:

Path path1;
Path path2; // These paths are in the visual tree
// Create a PathGeometry with some points
var points = new PointCollection();
points.Add(new Point(100, 0));
points.Add(new Point(100, 100));
points.Add(new Point(0, 100));
 
var pathFigure = new PathFigure();
pathFigure.StartPoint = new Point(0, 0);
pathFigure.Segments.Add(new PolyLineSegment() { Points = points });
 
var pathGeometry = new PathGeometry();
pathGeometry.Figures.Add(pathFigure);
 
// Assign this PathGeometry to both Paths
path1.Data = pathGeometry;
// No you don't you get an ArgumentException
path2.Data = pathGeometry;

When trying to re-assign this PathGeometry, an ArgumentException was thrown with the message Value does not fall within the expected range. After googling around it turned out others have come across this issue back in mid 2008. This issue is only present in Silverlight, not WPF, which definititely suggests it is a bug.

However, having received a completely meaningless exception, I decided to dig deeper to at least try to understand what went wrong and find a workaround.
Read More…

Disappearing Style Setters in Silverlight 3 and WP7 – fixed in Silverlight 4

I’ve come across a really annoying bug in Silverlight 3 that seems to be fixed in Silverlight 4, but still present in WP7. When creating a Style object in runtime, then setting that as the Style of an element in the visual tree, the Value properties in the Setters of the original Style are set to null!

The problem

I’ve come across this issue because I was trying to clone styles with the following extension method:

public static Style Clone(this Style style)
{
    if (style == null)
        return null;
    Style clonedStyle = new Style(style.TargetType);
    clonedStyle.BasedOn = style.BasedOn;
    foreach (Setter setterToCopy in style.Setters)
    {
        clonedStyle.Setters.Add(new Setter()
        {
            Property = setterToCopy.Property,
            Value = setterToCopy.Value
        });
    }
    return clonedStyle;
}

As you can see, this clone method is not doing anything complicated: it is simply iterating through the Setters of the Style and creating new Setter instances with the Property and Value of the original Setters – basically deep cloning the Style itself.

The issue in Silverlight 3

When I did clone a Style that had been created on the fly and had been assigned a the Style of an element, the values of Setters magically were set to null in Silverlight 3. The problem is visualized using the following simple code:
Read More…

Setting the StrokeDashArray using a Style in Silverlight

I’ve recently ran into an issue: I wanted to draw an element with a dashed stroke using a Style I’ve created on the fly. To my surprise I couldn’t.

The Problem

The type of the StrokeDashArray (that is defined on Shape) is a DoubleCollection. So naturally I tried setting a DoubleCollection instance as the Value of the Setter on the Style I created:

Style ellipse2Style = new Style(typeof(Ellipse));
// Setting a DoubleCollection as the Value of the Setter for StrokeDashArrayProperty doesn't work!
ellipse2Style.Setters.Add(new Setter(Ellipse.StrokeDashArrayProperty,new DoubleCollection() { 2, 2 }));
Ellipse2.Style = ellipse2Style;

Read More…

Silverlight 4 still displays large elements incorrectly

I’ve ran into the issue of Silverlight displaying large elements incorrectly in version 3. After reporting the issue on the official Silverlight forums it’s turned out that it’s a known issue that Silverlight renders elements larger than 32K incorrectly.

After Silverlight 4 released I was hoping that this issue is fixed. However, I was disappointed to see that it still exists. My problem with this bug is that I’m working on a charting application that supports zooming. The easiest way to do this applying RenderTransforms and ScaleTransforms to the elements plotted. However due to this bug zooming is limited until the zoomed element size is 32K – this sets a practical limit of about 70-150x zoom (based on the original element size) which in my case is a serious limitation.
Read More…

Silverlight bug when drawing large paths

I’m working on creating a zoom effect for a Silverlight Path object. This effect is easy to implement: I just have to apply a ScaleTransform and and a TranslateTransform within a TransformGroup for the Path (scale it up and move it on the screen where the user clicked to zoom). However when reaching a certain zoom level I’ve noticed some weird behaviour: the Path was drawn in some random, sometimes inverse way.

I’ve tracked the behaviour down to the point to when it seems that the problem is not with ScaleTransform but with Paths above a certain size. I’ve created a simple example project to reproduce the problem. The source can be downloaded here.

What I’m doing is drawing a simple rectangle with 5 points:
11

The issue

And I start to redraw it in larger sizes and at the same time re-positioning it to stay in the center (so I’m basically doing a centre zoom effect):
21

However when the size of the path is about 65 000px (or 80 times the height of the LayoutRoot – I used 1280*1024 resolution with the LayoutRoot grid being about 770px) the shape is drawn incorrectly:
3

Read More…

ASP.NET server side element names changed?

As far as I’ve known if the ClientID of a server control looked someting like this:

ctl00_WebPartManager1_184c801b_7c67_4967_be37_3ab10406f967_ctl00_linkVote1
.

Then the name sent on postback (which identified the control on the server side) was:

ctl00$WebPartManager1$184c801b$7c67$4967$be37$3ab10406f967$ctl00$linkVote1
.

But since some time the _ to $ conversion is not true any more. Instead the _ signs are randomly replaced by dollar signs. Recently the name sent back on postback is:

ctl00$WebPartManager1$184c801b_7c67_4967_be37_3ab10406f967$ctl00$linkVote1
.

This change screwed up quite a lot of client side manual __doPostback() codes I’ve written – most of the making these invokes due to JQuery addons.
Read More…

TFS – deleting old workspaces

I use Visual Studio 2008 on a daily basis however for some older projects I have to work with VS 2005. Recently our company has set a new Team Foundation Server in use and all active projects have been migrated there. In VS 2008 everything worked just fine.

However when trying to re-map a project to the same localtion as before (only from the new TFS server) I got the following error message: “The path [yourpath] is already mapped in workspace [yourworkspace]”. It took me a while to figure out what the resolution of the problem was.
Read More…

 Scroll to top