Skip to main content
Home Forums Silverlight Programming Programming with .NET - General Accessing Path.Data Programatically [PathGeometry]... is this possible?
15 replies. Latest Post by ferdna on December 8, 2008.
(0)
ssawchenko
Member
342 points
176 Posts
10-17-2008 6:40 PM |
Hello everyone,
I've seen a few other posts which are related to this I imagine, however, I never really found a workaround for the issue. I am looking to get access to the Path property "Data" [or rather, it's Data in the "Mini Language"].
<Path Name="shape_path" Fill="#FFFFFFFF" Stretch="Fill" Stroke="#FF000000" Width="92.5" Height="57.617" Data="M137,122 C227,161 168.5,204.5 228.5,159.5" />
So I want access to the Data field [shown above] in my C# code. I tried casting the Data property to a PathGeometry to get access to the Figures property [since from what I've been reading this is at least what property you SET to set the path figures collection], but I am getting a collection count of 0 even though it should read 4.
I read in another thread that this was not possible to do since casting the Data property to a PathGeometry is incorrect? Have I been misinformed, or is there an easy work around for this? I cannot control the XAML element [it is being loaded based on a xaml string obtained from a server], so there is a good chance it may contain this "Mini Language" format for Data [is that the correct term?].
Thank you for your time!
10-20-2008 11:39 AM |
Just bumping my post... I really need a solution to this, I'm kind of at a standstill in my project.
damonpayne
304 points
75 Posts
10-20-2008 12:00 PM |
The term is "Path Data Syntax".
http://msdn.microsoft.com/en-us/library/cc189041(VS.95).aspx
That seems odd that the PathGeometry is empty, I'll try it locally
{Edit: It is empty, I saw no way to get at the various path figures through TypeConverters, PathFigureCollection, Segments, or anything else. This would seem to be a bug? }
10-20-2008 12:59 PM |
I've read many other posts with people having a similar issue, although none have recieved a response from a MS rep that I have seen. This happened with the Beta 2 release from what people have been saying. Many other people are simply writing to the property and could find work arounds for that... but I need to READ the path geometry so none of their work arounds seem to fix my issue since I can't actually get access to the path data.
What I am trying to do is create do a serialization of sorts, where given a path element I can create and spit back a string with the XAML representation. To do this I needed to get access to the path data... which is where I ran into this issue.
10-20-2008 1:37 PM |
Even doing this:
var o = path.GetValue(Path.DataProperty);
gives me a PathGeometry object with an empty collection [Figures].
Could a MS rep comment on this? Is this a bug? I'm still developing in RC0 - I was hoping to get things a little more stable before I upgrade. I'll try upgrading today though just to see if it was fixed in the Silverlight 2 release.
10-20-2008 3:03 PM |
I'm running RTW and I get the same behavior, so upgrading is not likely to fix it
Yi-Lun L...
All-Star
25052 points
2,747 Posts
10-21-2008 8:04 AM |
Hello, this is by design. When using the Path markup mini language to define a Path's Data, you won't be able to get it in code behind. What you get is always empty. You have to use the full syntax.
<Path.Data>
<PathGeometry/>
...
</Path.Data>
A quick solution is to create a PointAnimtaion in Blend, and the syntax will automatically be expanded.
10-21-2008 12:08 PM |
Hmm... I guess the underlying problem is that I failed to fully read the msdn documentation on Path Markup Syntax which talks about the difference between StreamGeometry and PathFigureCollection Mini-Languages. I imagine what I did was take a StreamGeometry example from somewhere as my basis for the syntax and use that incorrectly.
As you can see from the preceding examples, the two mini-languages are very similar. It's always possible to use a PathGeometry in any situation where you could use a StreamGeometry; so which one should you use? Use a StreamGeometry when you don't need to modify the path after creating it; use a PathGeometry if you do need to modify the path.
That right there tells me I should have been using PathGeometry instead, although, my concern is that I have no control over the XAML string being fed into my application - so my fear is that I may actually end up getting the incorrect geometry from a user. I guess I will just have to make documentation very, very clear! From other threads I've read, we *used* to be able to access the Data property of a StreamGeometry, but I guess that was never intended.
Thank you so much for your help!
10-21-2008 1:22 PM |
Alrighty, new problem now.
I'm now using the correct path notation [actually I've taken the example DIRECTLY from the msdn page on path syntax to make sure I have everything correct], but I am getting a parse exception when I load the xaml.
I am loading the following string via XAMLReader.Load [I have included the wrapper namespace because it is my understanding that XAMLReader requires this]:
"<Canvas xmlns="http://schemas.microsoft.com/client/2007" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <Path Stroke="Black" Fill="Gray"> <Path.Data> <PathGeometry Figures="M 10,100 C 10,300 300,-200 300,100" /> </Path.Data> </Path></Canvas>"
And I am getting the XamlParseException "Invalid attribute value M 10,100 C 10,300 300,-200 300,100 for property Figures. [Line: 5 Position: 27]". Like I said, this example was taken directly from the msdn documentation, any ideas what is going wrong?
Thank you again for your help!
10-21-2008 1:55 PM |
So I found another thread which had the exact same parse error that I showed in my last post... and here the answer is:
"The PathGeometry.Figures property does not support the path "mini-language" syntax in Silverlight. You have to use the verbose explicit markup to describe those figures in your XAML."
Is that correct? Silverlight doesn't support that syntax for Figures? Am I able to get this confirmed - do I have to use the verbose method of markup in Silverlight? This is extremely frustrating given that many examples, even on MSDN, use this syntax.
Wolf Sch...
489 points
79 Posts
10-21-2008 3:07 PM |
PathGeometry.Figures does not support the Path minilanguage/syntax in Silverlight. However, Path.Data DOES support the Path minilanguage/syntax in Silverlight.
In Silverlight, if you use the minilanguage and set Path.Data, you get your intended path and its various parts rendered, but you do NOT get a run-time object tree representation of how that minilanguage was parsed such that you could walk into Figures, Segments, etc. You have to use the verbose form of markup by putting various PathFigure-type object elements under PathGeometry.Figures IF you want discrete run-time "parts" (and for best results, put some "Name" attributes on there so that you don't even need to walk, you can just use FindName).
BTW, in WPF, you also do not get object-tree representation of a path created via the mini-language. The only delta is that Silverlight only supports parsing/processing of the minilanguage on Path.Data whereas WPF supports it for either Path.Data OR PathGeometry.Figures.
PS: the MSDN article you linked two posts above is specifically the WPF version of the Path Markup Syntax information. You need to look at http://msdn.microsoft.com/en-us/library/cc189041(VS.95).aspx which is the Silverlight version. In general, you do have to keep an eye on whether you are looking at a WPF topic or a Silverlight topic when you look at MSDN, because many cases the TOC organization/titling etc. is similar between WPF and Silverlight but the information on the specific pages is often quite different because of the inherent technology differences.
10-21-2008 3:29 PM |
Thank you very much for the details - that was exactly what I was looking to get a grasp on. I'm embarrassed to say I didn't even see the difference between the MSDN and Silverlight documentation online... often I get to the documentation from searches and didn't even look at the breadcrumb notation at the top of the page to notice that page was for WPF. /facepalm
So really, I will always need access to the Figures collection [no matter if I was running in WPF or Silverlight] I would need to use the verbose syntax in order to get the run time object to manipulate. Good to know ^^
Again, thank you everyone, these forums have saved my sanity on multiple occasions!
Qbus
607 points
269 Posts
10-28-2008 7:48 PM |
I have the same issue. So what you are saying is that I need to make all my Paths like this:
<Path Margin="30.5,84.5,43.5,101.5" Fill="#FFFFFFFF" Stretch="None" Stroke="#FF000000" x:Name="MyPath"> <Path.Data> <PathGeometry> <PathFigure StartPoint="0.501983523368835,113.5"> <LineSegment Point="123.989723205566,0.5"/> <LineSegment Point="206.816864013672,110"/> <LineSegment Point="325.498016357422,4"/> </PathFigure> </PathGeometry> </Path.Data> </Path>
To make this work? That's pretty bad, expecially when you have an application with alot of Path's in it.
Why make is this difficult when you(Microsoft) want us to use Blend too? I mean, if you use Blend out of the box, which every designer will do, a Path is NOT written this way in the XAML. So when a designer have created alot of sweet looking stuff, we need to make it all over to be able to find the "points" of the Path's...
Sorry to be alittle negative, as I'm normally VERY happy about Silverlight, I just think this is weird.
10-30-2008 9:24 PM |
Well ... I'd shy away from stating you HAVE to make your Path's this way because of the designer issue you mention. An interesting read on the whole using designer-produced XAML issue is this whitepaper: http://windowsclient.net/wpf/white-papers/thenewiteration.aspx
That is actually a WPF oriented whitepaper but the general ideas are similar.
I think what the authors of the paper would suggest would be accept the path as designer output and do your darndest to do what you need to do with a transform that treats the finished path as a rect, but that isn't always possible of course.
I don't know all the specifics of Path.Data, but here is one thing I do know: the issue is the same in WPF - there's no accessible object model backing for an object tree that gets made out of Path.Data. It's a vector that renders but it's not there piecewise in a visual tree or otherwise. At one point in the prerelease WPF lifecycle, there was a review of every "minilanguage" that was enabled in WPF XAML, and that review was pretty much driven by the issues you mention: how can anyone (a tool, a human being, any serialization roundtripping) discover what is valid or invalid in that minilanguage? Why not instead express it more object-wise where things like underlying object models can better make discoverable and enforce the rules? Path.Data however was a special case where the minilanguage was permitted to stay, and so here we are.
11-10-2008 5:40 AM |
I haven't tried it out yet, but this seems to solve my problem at least:
http://www.codeproject.com/script/Forums/Edit.aspx?fid=1529956&floc=/KB/silverlight/PathAnimation.aspx
ferdna
108 points
49 Posts
12-08-2008 2:58 PM |
url that you posted doesn't take to article.. here it is:
http://www.codeproject.com/KB/silverlight/PathAnimation.aspx
Accessing Path.Data Programatically [PathGeometry]... is this possible?