This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have been using property descriptors in my YBindings (and sometimes XBindings), which worked fine prior to version 6 (after you resolved a couple of issues long ago). However, coming back to the charting with version 6 I find this no longer works. Below is a demo. I am creating a property descriptor that encapsulated a function (square). When I use this inside a conventional property with Items for the ItemsSource it works fine (click the first button). When I use the same property descriptor directly in the YBinding it doesn't work (restart and click the second button). However, I can use the same binding for the int boxes, which get the correct values, which shows there is nothing wrong with the binding. This definitely used to work for LineSeries as well. It appears to me that DataSeries.UpdatePropertyInfo is coded to assume a string path, which is not the case when a PropertyDescriptor or DependencyProperty (rather than the wrapper) is used. Here is the XAML
Code Behind (leaving out the usings, which cause problems in the rendering) namespace ChartPdProblem
{
///
} |
|
|
Hello Peter Apologies for this breaking change. What you have seen in the source code resulted in a phenomenal performance improvement. I had forgotten about the case of using a property descriptor. I'll be investigating ways to detect these scenarios tomorrow and will have it fixed for you within 2 days. Jason Fauchelle |
|
|
Hi Jason, Thanks for looking into this. I am all for performance improvements, though performance wasn't bad to begin with! I certainly hope that handling property descriptors would not hurt performance much. I also confirmed that it currently doesn't work for dependency properties (as opposed to the CLR wrappers), and presumably it will not work for attached properties either. I also confirmed that it doesn't work for binding paths that refer to sub-properties (e.g., "Property.SubProperty"). In general I would hope that it can work for any valid binding. Peter |
|
|
Hi Jason, After thinking about this some more I couldn't resist trying my hand at a fix, which is a replacement for DataSeries.UpdatePropertyInfo (see below). It handles all the cases I can think of, including when the binding uses a value converter, which seems to have be ignored in the current code. I think it is quite efficient for the case of property descriptors, dependency properties, and binding directly to the source object, and I would think is okay for other cases. Peter Here's the code:
|
|
|
Hello Peter This is a very nice piece of code, thanks for posting this! My original approach was just going to use an equivalent of your BindingPropertyInfo for ALL cases apart from the basic "name of property with no converter". However, all your property info variants provide a more efficient solution for cases that don't necessarily need to use the full binding, so I've included this in the charting product. I just made a couple of changes to BindingPropertyInfo that you may be interested in: You only need to SetBinding in the constructor, rather than every time in the GetValue method - this improves the performance. Also, it looks like your BindingPropertyInfo class could cause the converter to be applied twice - first by applying the binding to the Dummy, and then again in the PropertyInfoWrapper base class. To resolve this I simply override the main GetValue method in the BindingPropertyInfo. This will be available in the next nightly build. Let us know if there are any cases that you need that seem to have been missed and I'll add it in. Looks like this already has full coverage though. Jason Fauchelle |
|
|
Hi Jason, Glad the code I posted is of use! I did initially try the SetBinding in the constructor, but it seemed like it didn't work, though I didn't understand why. I'll try your update. I'm sure you are right about the converter being applied twice--oops. Peter |
|
|
Hi Jason, I downloaded and tested the latest nightly build, and I find that in the case of a complex path (where it uses BindingPropertyInfo) it does not work. The other cases work fine. When I move the SetBinding call to the GetValue (after setting DataContext) then it works fine (I also made the base _binding field protected instead of private, so BindingPropertyInfo.GetValue could access it). I found it puzzling that it doesn't work to call SetBinding in the constructor, but guessed that when the DataContext is changed maybe the binding does not update immediately, but with some lower priority. To test this I moved the SetBinding back to the constructor and inserted a "wait" after setting the DataContext in GetValue as follows:
With this wait it does work fine. However, I am definitely not recommending this approach as a fix! Better to just move the SetBinding in the GetValue. Perhaps there is a better way to get the binding to update _extractor.Value immediately? Peter |
|
|
Thanks Peter I clearly didn't try this out correctly. I had forgotten one thing - by setting the DataContext of the extractor to null before setting the binding in the constructor causes it to work perfectly fine from then onwards. It's unusual that this works, but it is a technique that I've used for a long time and I think it is suitable. This allows the binding to still be set in the constructor which helps the performance a lot. This will be fixed in the next nightly build. Jason Fauchelle |
|
|
Hi Jason, That seems weird, but I tried it out and it indeed works. Nice tip! I was googling this question earlier, and I read several questions that this would have been the best answer to. Peter |
|