Programming with .NET - General

Re: Re: Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ferdna — Mon, 08 Dec 2008 19:58:32 GMT

url that you posted doesn't take to article.. here it is:

http://www.codeproject.com/KB/silverlight/PathAnimation.aspx

Re: Re: Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

Qbus — Mon, 10 Nov 2008 10:40:07 GMT

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

Re: Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

Wolf Schmidt (MSFT) — Fri, 31 Oct 2008 01:24:19 GMT

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.

Re: Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

Qbus — Tue, 28 Oct 2008 23:48:34 GMT

I have the same issue. So what you are saying is that I need to make all my Paths like this:

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.

Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Tue, 21 Oct 2008 19:29:09 GMT

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!

Re: Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

Wolf Schmidt (MSFT) — Tue, 21 Oct 2008 19:07:19 GMT

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.

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Tue, 21 Oct 2008 17:55:04 GMT

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.

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Tue, 21 Oct 2008 17:22:12 GMT

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!

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Tue, 21 Oct 2008 16:08:29 GMT

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!

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

Yi-Lun Luo - MSFT — Tue, 21 Oct 2008 12:04:36 GMT

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>

...

</Path.Data>

A quick solution is to create a PointAnimtaion in Blend, and the syntax will automatically be expanded.

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

damonpayne — Mon, 20 Oct 2008 19:03:28 GMT

I'm running RTW and I get the same behavior, so upgrading is not likely to fix it

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Mon, 20 Oct 2008 17:37:42 GMT

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.

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Mon, 20 Oct 2008 16:59:31 GMT

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.

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

damonpayne — Mon, 20 Oct 2008 16:00:00 GMT

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? }

Re: Accessing Path.Data Programatically [PathGeometry]... is this possible?

ssawchenko — Mon, 20 Oct 2008 15:39:15 GMT

Just bumping my post... I really need a solution to this, I'm kind of at a standstill in my project.