I've been sitting lately on the topic of Reflection, mainly with the purpose of instantiating a New class and setting properties on fields.. By path... Where, for example I might have a class called Games, with public property -
Game myGame = new Game()
myGame.GamingProperties.HowToPlay = "bla bla bla";
myGame.StateProperties.CreationTime = DateTime.Today;
So for example I have to set value (with reflection magic) on property with a path of: "GamingProperties.HowToPlay"
Until now I've been using the "PropertyReflector" class by Guy Mahieu - which does exactly what I need, but slowly when it comes to reflecting/de-serializing 100,000-s of objects.
Bit later I found out that it is possible to set property values much much faster by using "Expression Trees" (and a project like "FastReflection") was a good example.. But I got stuck now with the FastReflection because I can't set values properly on nested types...
Anyhow – the question is – whether System.Windows.PropertyPath could help me somehow with all this? Is it even related? Maybe I could use it for my needs, or use the .Binding methods (that are closely related with System.Windows.PropertyPath)?
I hope that I was clear and not too messy with my question and I will be grateful for any hints, suggestions...
The short answer is no. The PropertyPath is used by the WPF binding system to tie DependencyProperties to other properties (either dependency or regular). When binding to a dependency property, the binding system can use the property path to resolve the bound property using WPF metadata. When binding to a CLR property, it has to use .NET reflection to resolve the property.
In either case, it's not generally used to set CLR properties, but it can with two-way bindings.
It won't provide a speed boost for that many objects and I doubt it is a solution to your problem.